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ABSTRACT 


The  purpose  of  this  thesis  is  to  evaluate  the  Staff  Planning  and  Decision  Support 
System  (SPADS).  The  analysis  presented  uses  the  Modular  Command  and  Control 
Evaluation  Structure  (MCES),  a  structured  approach  to  evaluate  C2  systems  using 
standard  and  evolving  operational  research  tools.  The  analysis  answered  the 
following  three  problems  by  assessing  the  effectiveness  of  SPADS.  Did  SPADS 
provide  the  V  Corps  commander  and  his  staff  with  the  ability  to  exercise  command 
and  control  of  combat  assets  to  meet  overall  mission  objectives?  Did  SPADS 
demonstrate  that  the  dispersed  command  post  concept  enhanced  command 
survivability?  Did  SPADS  evolve  as  a  command  and  control  force  effectiveness 
system  for  the  V  Corps  DCP  based  upon  operational  lessons  learned?  Appropriate 
measures  of  performance,  effectiveness,  and  force  effectiveness  were  identified  to 
answer  these  problems.  These  measures  and  their  assessment  are  presented  as  a 
strawman  for  consideration  by  the  analytical  community.  As  SPADS  evolved  from 
August  1981  to  March  1985,  it  provided  distinct  advantages  to  the  V  Corps 
commander  and  his  staff  in  terms  of  effective  C2  mission  orientation,  enhanced 
command  survivability,  and  increased  C2  force  effectiveness. 
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The  purpose  of  this  thesis  is  to  present  an  analysis  of  the  Staff  Planning  and  Decision 


Support  System  (SPADS).  This  system  was  a  Defense  Nuclear  Agency  (DNA) 


exploratory  development  initiative  in  response  to  U.S.  Army  requirements  for  Command, 


Control  and  Communication  (C3)  survivability  of  theater  nuclear  forces.  The  V  Corps 


dispersed  command  post  (DCP)  concept  was  the  basis  for  enhancing  survivability.  In  its 


acquisition,  SPADS  represents  an  evolutionary  development  with  each  phase  based  upon 


the  results  of  lessons  learned  during  field  exercises  in  central  West  Germany. 


The  analysis  presented  uses  the  Modular  Command  and  Control  Evaluation  Structure 


(MCES)  to  assess  the  effectiveness  of  SPADS.  MCES  is  a  structured  approach  to  evaluate 


C3  systems  using  standard  and  evolving  operational  research  tools.  Previous  applications 
of  MCES  at  the  Naval  Postgraduate  School  (NPS)  have  focused  on  theater-level  and  higher 
C2  issues.  A  common  characteristic  of  these  analyses  was  the  future  focus  on  evaluating 
systems  and  testbeds.  This  is  the  first  MCES-based  evaluation  of  a  tactical  C3  system  that 


evolved  from  its  conceptual  stage  to  operational  performance. 


A.  MCES  EVOLUTION 


The  initial  development  of  MCES  grew  out  of  a  challenge  to  determine  the  force 
effectiveness  of  C2  systems.  A  methodology  was  needed  to  describe  C2  systems 
architecture  which  would  allow  analysts  to  measure  C2  systems  response  and  attribute  the 


effectiveness  of  that  response  to  the  elements  and/or  structural  relationships  which  form  the 


C2  system  [Ref.  l:p.  13|.  In  1984  Dr.  Ricki  Sweet  and  Lt.  Col.  Thomas  Fagan  III  chaired 


a  conference  which  focused  on  identifying  issues  and  topics  an  analyst  would  address 


when  evaluating  a  C-  system  in  terms  of  its  contribution  to  force  effectiveness.  Five 
working  groups  were  formed  to  address  the  following  subjects:  Definitions,  Conceptual 
Models,  the  Identification  of  Measures  of  Effectiveness  (MOEs),  Evaluation  Techniques 
and  Approaches,  and  an  overall  appraisal  of  the  current  status  and  future  course  of  MOE 
analysts  [Ref.  l:pp  24-27]. 

Subsequent  workshops  and  conferences  further  defined  expressed  interests  in  and  the 
need  for  further  attention  to  C2  systems.  A  "strawman"  was  developed  by  Drs.  Morton 
Metersky,  Michael  Sovereign  and  Ricki  Sweet  to  provide  a  framework  for  effectiveness 
analysts  and  deliberation  at  the  1985  Military  Operations  Research  Society  (MORS) 
sponsored  workshop.  This  led  to  the  publishing  of  an  integrated  document  describing 
MCES  in  June  1986. 

MCES  was  designed  to  be  applicable  to  any  C2  system,  to  be  modified  or  altered  to  fit 
any  C2  system  of  interest.  MCES  methodology  continues  to  evolve  in  order  to  resolve  key 
C2  issues.  New  C2  tools  and  models  have  been  identified,  developed  and  integrated  into 
MCES. 

Numerous  efforts  at  NPS  have  been  directed  towards  the  application  of  MCES  to 
various  command  and  control  issues.  During  the  last  two  years,  six  master's  of  science 
degree  theses  have  been  completed  using  MCES  at  NPS.  These  theses  spanned  the  range 
from  applying  MCES  as  a  framework  for  acquistion  management  to  analyzing  the 
Identification  Friend,  Foe  or  Neutral  (IFFN)  Joint  Testbed  to  evaluating  C2  components  of 
the  Strategic  Defense  Initiative  (SDI)  architecture. 

B  .  MCES  METHODOLOGY 

MCES  was  developed  during  the  1980s  as  a  structured  approach  to  evaluate  C2 
systems  and  architectures.  MCES  defines  "architecture"  as  a  description  of  an  integrated 
set  of  systems  whose  physical  entities,  structure,  and  functions  are  coherently  related.  This 


representation  of  the  architecture  provides  the  ability  to  measure  the  C-  system  response 
and  its  effectiveness  in  directing  forces  to  accomplish  their  mission.  MCES  uses  standard 
and  evolving  operations  research  tools,  and  attempts  to  integrate  previous,  diverse  efforts 
of  decision  makers  and  analysts  to  provide  a  concise  (devaluation  structure  [Ref.  l:p.  13]. 

MCES  is  composed  of  seven  sequential  modules  which  guide  an  analyst  through  a 
comprehensive  C2  evaluation.  Figure  1.1  presents  the  graphic  structure  of  MCES 
methodology. 

The  first  module  is  used  by  both  the  analyst  and  the  operational  user  to  specify  the 
particular  C2  problem.  The  next  three  modules  employ  the  terminology  and  theory  of 
MCES  to  describe  the  C2  system  architecture.  This  permits  the  analyst  to  model  the  C2 
system  and  its  operation.  The  methodology  integrates  the  physical  elements  of  the  system 
with  its  process  functions  into  a  structural  framework.  In  the  fifth  module,  measures  are 
identified,  based  upon  the  C2  system  bounding,  which  will  be  used  to  evaluate  the  C2 
architecture.  The  sixth  module  requires  appropriate  data  for  measurement.  The  seventh 
module  aggregates  and  evaluates  the  results  for  presentation  to  the  decision  maker  [Ref. 
2:pp.  10-23].  (A  more  detailed  explanation  of  how  MCES  is  applied  is  provided  in 
Appendix  D.) 

C.  SPADS  BACKGROUND 

The  U.S.  Army  V  Corps,  headquartered  in  Frankfurt,  West  Germany,  attempted  to 
employ  a  dispersed  command  post  (DCP)  configuration  in  the  early  1980s.  Despite  early 
success  with  concepts  and  their  employment,  the  corps  was  constrained  by  Army  hardware 
and  doctrine.  Following  several  exercises  that  employed  the  early  Target  Acquisition  and 


Planning  (TAP)  microcomputer  workstations,  V  Corps  requested  assistance  from  DNA  for 
the  implementation  of  their  DCP  concept.  In  September  1981,  DNA  introduced  the  Staff 
Planning  and  Decision  Support  (SPADS)  system  at  V  Corps  as  the  focus  of  its 
Exploratory  Development  Program  (EDP)  in  Support  of  TNF  C3  Survivability  (Support 
of  V  Corps/8ID  Dispersed  Command  Post)."  DNA  employed  V  Corps  as  the  proof  of 
concept  experiment  (POCE)  testbed  for  SPADS  from  September  1981  through  December 
1984.  V  Corps  energetically  used  this  evolutionary  command  and  control  system  in  every 
field  training  and  command  post  exercise  throughout  the  1980s. 

The  dispersed  command  post  concept  was  the  basis  for  enhancing  survivability.  V 
Corps  Headquarters  operated  from  dispersed  cells,  representing  the  traditional  Corps 
Tactical  Operations  Center  (CTOC),  rather  than  from  one  large  center  that  could  present  a 
lucrative  target.  The  communications  links  between  and  among  the  dispersed  cells  were 
provided  by  the  Army's  Tactical  Area  Switching  System  (TASS). 

SPADS  was  a  distributed  information  processing  system  that  supported  C3  functions 
at  multiple  geographic  locations.  The  system  was  designed  for  use  in  vans,  tents, 
buildings,  or  armored  command  vehicles  by  functional  staff  personnel  and  commanders. 
The  SPADS  architecture  consisted  of  a  co-located  group  of  staff  duty  stations  linked  by  a 
local  area  network  to  form  a  module.  Several  modules  were  then  interconnected  by 
communication  gateways  through  Army  tactical  communications  to  form  a  distributed, 
wide  area  network.  The  capabilities  of  the  staff  duty  stations  consisted  of  text  editing, 
electronic  mail,  graphics  and  overlays,  a  relational  database  management  system,  map  and 
photo  correlation,  spreadsheet  models,  and  functional  area  algorithms. 

D.  NATURE  OF  THE  PROBLEM 

This  thesis  addresses  the  question:  How  effective  was  the  SPADS  system  in  the  V 
Corps  sector  of  the  Central  Army  Group  (CENTAG)  region  in:  (1)  providing  decision 


makers  with  the  means  to  access  and  employ  their  combat  assets  to  meet  overall  mission 
objectives;  (2)  demonstrating  that  the  DCP  concept  enhanced  command  survivability;  and 
(3)  evolving  as  a  command  post  support  system,  based  upon  operational  lessons  learned? 

To  elaborate,  this  thesis  will  specifically  attempt  to  assess  SPADS'  effectiveness  in  the 
following  three  problem  areas: 

1 .  Did  SPADS  provide  the  V  Corps  commander  and  his  staff  with  the  ability  to  exercise 
command  and  control  of  combat  assets  to  meet  overall  mission  objectives? 

2.  Did  SPADS  demonstrate  that  the  dispersed  command  post  concept  enhanced 
command  survivability? 

3 .  Did  SCAT'S  evolve  as  a  command  and  control  force  effectiveness  system  for  the  V 
Corps  DCP  based  upon  operational  lessons  learned? 

The  resolution  of  the  first  problem  requires  a  measure  of  effectiveness  (MOFE) 
derived  as  a  function  of;  (1)  capability  to  achieve  the  C3  system’s  objectives  interpreted  as  a 
function  of  flexibility,  availability,  interoperability,  and  responsiveness;  (2)  structural 
components  interpreted  in  terms  of  timeliness;  and  (3)  the  physical  entities  interpreted  in 
terms  of  capacity. 

The  second  problem  addresses  command  survivability  as  a  function  of  dispersion, 
redundancy,  and  continuity  of  operations.  And  the  third  problem  measures-across  levels 
of  operational  capacity-the  evolution  of  C2  force  effectiveness  together  with  survivability. 
This  final  measure  of  command  and  control  growth  is  thus  derived  as  a  function  of  the 
MOFE  from  Problem  1  and  the  MOE  from  Problem  2,  wtith  respect  to  time. 

Appropriate  data  for  these  three  problems  were  gathered  from  after  action  repons, 
external  evaluations,  and  operational  experience.  These  data  were  generated  during 
numerous  field  training  and  command  post  exercises  from  1981  through  1985.  A 
worksheet  was  developed  to  select  specific  data  for  the  measures  of  performance, 
effectiveness,  and  force  effectiveness. 
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As  indicated  in  the  preceeding  paragraphs,  several  of  the  measures  are  functions  of 
other,  lower  level  measures.  For  the  purpose  of  this  thesis,  the  values  are  defined  as  the 
unweighted  sum  of  the  constituent  measures  of  performance.  Only  replication  and  external 
validation  can  present  more  certainty  on  the  assessment  of  factors  and  their  aggregation. 
These  measures  and  their  assessment  are  presented  as  a  strawman  for  consideration  by  the 
analytical  community. 

E.  THESIS  ORGANIZATION 

This  thesis  summarizes  how  MCES  methodology  was  specifically  applied  to  evaluate 
the  SPADS  system.  The  doctrinal  definition  of  a  forward  deployed,  heavy  corps  is 
discussed  in  terms  of  MCES  in  Chapter  II.  Chapters  III,  IV  and  V  present  an  MCES 
analysis  of  the  three  phases  of  the  SPADS  program.  Finally,  Chapter  VI  provides 
conclusions  and  recommendations  concerning  the  SPADS  program,  evolutionary 
development,  and  the  MCES  methodology. 


ss 


II.  THE  CORPS  BASELINE 


A.  PROBLEM  DEFINITION 
1 .  Background 

In  the  early  1980s,  existing  and  projected  Army  communications  systems 
inhibited  rather  than  enabled  command  mobility.  The  standard  small  set  of  known.  Fixed 
command  posts  and  communications  nodes  was  vulnerable  to  disruption  and  destruction  by 
Soviet  radio  electronic  combat  units.  One  solution  to  this  vulnerability  was  to  dramatically 
increase  the  number  of  C3  targets  and  mobility  and  to  achieve  position  location  uncertainty. 
There  were  other  technical  alternatives,  but  military  application  of  these  technologies 
resulted  in  prohibitive  unit  costs  and  frequent  program  curtailment  or  termination.  Some 
means  had  to  be  found  to  substantially  lower  survivability  costs. 

Potential  solutions  started  to  surface  in  military  efforts  to  exploit  the  growing 
power  of  the  microprocessor.  The  DNA,  the  Army’s  Training  and  Doctrine  Command 
(TRADOC),  and  V  Corps  all  initiated  programs  to  achieve  enhanced  C2  survivability  which 
were  heavily  dependent  on  new  approaches  to  communications  and  command  post  decision 
aids.  By  1981  V  Corps  began  vigorously  testing  innovative  command  and  staff  procedures 
to  support  command  post  (CP)  survivability,  mobility,  and  effectiveness.  The  corps  main 
CP  used  a  closed-circuit  TV  system  to  support  command  and  staff  briefings  in  the 
consolidated  Corps  Tactical  Operations  Center  (CTOC).  Original  plans  to  disperse  the 
CTOC  had  been  defeated  due  to  an  inability  to  transmit  a  secure  video  signal  carrying  text 
and  graphic  information. 

Meanwhile,  TRADOC  identified  certain  initiatives  which  the  Army  could  pursue 
to  enhance  corps  and  division  battle  coordination  efforts,  including  [Ref.  3:p  3-23]: 
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1 .  Dedicating  intelligence  (Intel)  and  fire  support  element  (FSE)  personnel  to  work 
continuously  on  analyzing  data  throughout  the  depth  of  the  battlefield 

2.  Placing  a  field  artillery  officer  in  the  CTOC  support  (formerly  the  intelligence) 
element  to  process  quick  reaction,  perishable,  high  priority  targets  directly  to  the 
appropriate  attack  means 

3 .  Dedicating  a  CTOC  support  element  analyst  to  develop  quick  reaction  priority  targets 

4.  Co-locating  and  training  the  G2/G3,  FSE,  tactical  command  post  (TAC  CP),  and 
other  staff  elements  designated  by  the  commander  to  ensure  synchronization  of  the 
deep,  close-in,  and  rear  battles 

5 .  Introducing  the  use  of  microcomputers  in  the  FSE  and  CTOC  support  element  to 
develop,  analyze,  and  prioritize  targets  in  a  rapid  and  continuous  manner 

6.  Using  closed-circuit  TV  and  non-voice  data  links  among  critical  staff  elements 

During  this  same  period,  DNA  fielded  the  experimental,  microcomputer-based 
Target  Acquisitions  Planning  (TAP)  system  in  V  Corps.  The  purpose  of  TAP  was  to 
develop,  analyze,  and  prioritize  artillery  targets  in  a  rapid  and  continuous  manner.1  The  V 
Corps  commander  recognized  a  possible  linkage  between  TAP  and  the  efforts  to  disperse 
command  posts.  In  May  1981,  V  Corps  contacted  DNA  directly  to  request  an  expansion  of 
the  TAP  program  to  support  corps  operations.  First,  V  Corps  requested  that  DNA  provide 
personnel  to  conduct  an  in-depth  analysis  of  corps  requirements  during  the  June  1981 
command  post  exercise.  Second,  the  commander  requested  that  an  expansion  of  the  TAP 
program,  geared  to  the  corps  dispersed  command  post  concept,  be  tested  in  September 
during  REFORGER  81.  [Ref.  4:pp.  1-2] 


'The  TAP  system  employed  microcomputer  automation  to  provide  an  integrated 
capability  for  U.S.  and  NATO  targeting  staffs  to  identify  Warsaw  Pact  echeloned  forces  in 
near  real  time.  Intelligence  and  fire  support  staffs  today  employ  TAP  in  conjunction  with 
other  automated  systems  to  streamline  the  targeting  process.  It  provides  staff  officers  with 
an  interim  capability  until  such  systems  as  All  Source  Analysis  System  (ASAS)  and 
Advanced  Field  Artillery  Tactical  Data  System  (AFATDS)  are  fielded  in  the  early  1990s. 
[Ref.  7:p.  27] 


The  dispersed  command  post  concept  offers  the  possibility  of  reducing  and/or 
disguising  both  the  electronic  and  physical  signatures  of  the  consolidated  CP.  Nearly  all  of 
the  communications  and  other  electronic  equipment,  vehicles,  and  facilities  found  in  the 
corps  CP  are  also  found  in  lower  echelon  CPs.  If  these  assets  could  be  reassembled  as 
smaller  modules  and  then  dispersed  on  the  battlefield,  the  enemy  would  find  it  very  difficult 
to  distinguish  the  main  corps  CP  from  many  other,  lower  echelon  CPs.  In  addition,  once 
the  CP  is  broken  into  smaller  units,  it  is  much  easier  to  accommodate  the  components  in 
civilian  structures  or  small  wooded  crea;;.  Supporting  communications  links  could  then  be 
maintained  at  smaller  regional  nodes  in  a  further  effort  to  reduce  the  electronic  signature. 

The  traditional  corps  CP  configuration  in  the  early  1980s  presented  a  target  of 
some  150-meter  radius.  Either  a  small  nuclear  weapon  or  a  well-targeted  conventional 
attack  could  have  destroyed  nearly  all  of  the  C2  capabilities.  Given  the  "kill  radius"  of  even 
small  nuclear  weapons  against  CPs  and  other  C3  facilities,  DNA  recommended  a  DCP 
system  that  called  for  the  dispersion  of  the  corps  main  CP-particularly  the  CTOC-into 
several  modules  that  would  be  separated  by  a  minimum  distance  of  ten  kilometers.  DNA 
envisioned  that  this  system  would  be  extended  throughout  the  corps  CPs  and  eventually 
down  to  the  division  CPs.  The  corps  CP  would  then  be  dispersed  throughout  an  area 
approximately  40  kilometers  by  50  kilometers. 

Despite  expected  difficulties  in  coordination,  DNA  concluded  in  1981  that  the 
DCP  offered  the  greatest  probability  for  the  survivability  of  corps  C2  on  the  modem 
battlefield.  The  conclusion  reached  by  DNA  was  further  reinforced  by  emerging  U.S. 
Army  doctrine  revealed  in  TRADOC  Pamphlet  525-5,  The  AirLand  Battle  and  Corns  86. 
dated  25  March  1981,  which  strongly  encouraged  the  dispersion  of  critical  C2  facilities. 
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To  test  this  concept,  DNA  felt  it  necessary  to  establish  a  proof  of  concept  testbed 
at  an  operational  corps.  In  May  1981,  the  V  Corps  Commanding  General  sent  an  electronic 
message  to  DNA  requesting  assistance  with  a  concept  to  employ  microcomputers  to 
support  C2  operations  in  a  dispersed  command  post.  DNA  took  this  opportunity  to 
establish  a  testbed  at  V  Corps  with  the  objective  of  proving  the  DCP  concept  while 
developing  an  automated  C2  system  to  enable  its  effective  test  and  evaluation. 

3.  Evolutionary  Acquisition 

Evolutionary  Acquisition  (EA)  is  not  a  cure-all  for  the  real  or  perceived  ills  of  the 
U.S.  acquisition  process;  but  it  does  hold  promise  to  help  field  command  and 
control  (C2)  systems  sooner,  at  lower  cost  and  with  higher  user  satisfaction  than 
other  approaches.  [Ref.  5:p.  23] 

The  purpose  of  evolutionary  acquisition  is  to  be  able  to  field  critically  needed 
operational  capabilities  (OCs)  within  six  to  12  months,  rather  than  the  years  that  would  be 
required  under  standard  acquisition  policies.  Deployment  of  the  initial  operational 
capability  (IOC)  is  accomplished  during  the  first  year.  The  operational  users  conduct 
studies  and/or  exercises  in  their  own  tactical  environments  with  on-site  technical  assistance 
from  the  contractor.  Command  and  control  procedures — along  with  system  capabilities — 
evolve  and  are  tested  and  refined  during  each  field  test  and  exercise. 

Two  critical  components  of  this  approach  are  incremental  testing  and  user 
involvement.  Hirsch  noted  that: 


A  premise  involved  in  using  EA  [Evolutionary  Acquisition]  to  acquire  C2  systems 
is  that  C2  systems  are  tested  incrementally  to  determine  whether  the  core  system  (or 
core  system  plus  incremental  upgrades  to  that  system)  meets  the  operational 
requirement.. ..Therefore,  users  gain  more  extensive  experience  and  make 
recommendations  for  establishment  of  operational  requirements  for  subsequent 
system  increments.  This  process  of  requirement  evolution  and  introduction  of 
upgrades  distinguishes  the  evolutionary  approach  from  the  more  classic  weapon 
acquisition  process.  [Ref.  5:p.  26] 


Each  operational  capability  cycle  is  repeated  to  respond  to  changing 
requirements,  to  counter  the  new  threat  systems  or  techniques,  and  to  take  advantage  of 
new  and  rapidly  maturing  technologies.  Enhancements  to  the  system  are  made  within  each 
cycle  by  adding  or  replacing  components  and  by  integrating  new  software  that  is  tailored  to 
specific  military  requirements. 

Subsequent  operational  capabilities  consolidate  incremental  enhancements  or 
involve  complete  system  upgrades  to  take  advantage  of  major  advances  in  microcomputer 
technology.  The  result  is  a  fully  integrated  system,  tailored  to  meet  the  operational  user's 
specific  needs.  The  fnal  operating  capability  remains  undefined,  due  to  the  evolutionary 
nature  of  this  developmental  approach  and  the  continued  implementation  of  hardware 
and/or  software  modifications  arising  from  user  requirements. 

Operational  capability  cycles  can  be  of  different  lengths  or  quantity.  Milestones 
are  normally  sequential  but  can  overlap.  The  initial  responsibility  of  the  operational  user  is 
to  develop  valid  requirements.  This  requires  an  understanding  of  procedures  which  can  be 
automated  to  meet  the  user's  operational  needs.  Once  the  hardware  configurations  and 
software  utilities  are  designed,  the  operational  user  has  to  identify  and  develop  data 
structures  and  select  those  procedures  to  be  automated.  At  the  same  time,  the  operational 
user  plans  manpower  and  training  requirements  for  the  evolving  system.  How  the 
commander  ranks  these  responsibilities  strongly  determines  the  initial  success — or  lack 
thereof — of  early  exercises  and  tests. 


The  SPADS  evolutionary  development  approach  arose  from  the  evolutionary 
acquisition  concept.  This  process  was  mandated  by  Department  of  Defense  Instruction 
(DODI)  5000.2  (System  Acquisition)  which  provided  a  method  to  rapidly  refine  an 
automated  command  and  control  system  that  employed  state-of-the-art  technology  guided 
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by  user  requirements.  DODI  5000.2  devised  a  new  approach  to  counter  the  following 
impediments  to  rapid  fielding  of  technological  advances: 

1 .  A  ten-year  lag  between  research  and  development  (R&D)  and  effective  system 
implementation,  resulting  in  built-in  obsolescence 

2 .  The  ineffectiveness  of  systems  that  cannot  respond  to  changing  U.S.  Army  doctrine 

3 .  The  lack  of  affordability  of  automated  systems  that  are  tailored  to  user  requirements 

SPADS  evolutionary  development  produced  its  greatest  benefits  for  V  Corps 
when  the  operational  users  initiated  a  critical  dialogue  with  DNA  and  the  systems 
integrator.  Hirsch  noted  that: 

In  using  EA  [Evolutionary  Acquisition]  to  acquire  C2  systems,  a  major  premise  is 
that  the  real  user— working  in  a  close,  continual  relationship  with  the  developer  and 
supporter— should  have  a  major  voice  in  formulating  operational  requirements  and 
defining  detailed  system  characteristics.  [Ref.  5:pp.  24-26] 

As  a  consequence  of  this  approach,  the  resulting  SPADS  system  was  smaller, 
lighter,  more  rapidly  deployable,  and  required  less  manpower  to  operate  and  maintain. 

5 .  Problem  Focus 

The  three  problems  identified  in  Chapter  I  will  be  examined  under  four 
conditions  throughout  the  remainder  of  this  thesis.  The  four  conditions  consist  of  the  V 
Corps  baseline  and  the  three  SPADS  operational  capabilities  (detailed  in  Chapters  III 
through  V).  Each  condition  will  be  evaluated  using  MCES,  then  the  problems  will  be 
addressed  at  the  conclusion  of  each  evaluation. 

B  .  BOUNDING  THE  V  CORPS  SYSTEM 

In  the  terms  of  MCES,  the  V  Corps  C2  system  consists  of:  (1)  physical  entities — the 
equipment,  personnel  and  command  posts^2)  structure — the  hierarchical  relationships, 
staff  procedures,  concepts  of  operation  and  information  flow  patterns;  and  (3)  the  C2 
process — what  the  command  and  control  system  was  doing  [Ref.  2:pp.  11-12].  (Appendix 


E  provides  a  detailed  definition  of  the  Army's  forward  deployed  corps  in  terms  of  mission, 
organization,  operational  concepts,  threats  to  the  corps,  commander  and  staff,  command 
posts,  and  communications  support.) 

Emphasizing  the  battle  management  functions  necessary  to  control  a  forward  deployed 
corps  in  central  West  Germany,  the  V  Corps  C2  system  could  be  defined  structurally  in 
terms  of  its  hierarchical  relationships,  its  geographical  areas  of  responsibility  within  the 
Central  Army  Group  (CENTAG),  and  the  information  flow  patterns  between  command 
posts.  Hierarchically,  the  corps  received  its  commands  from  CENTAG;  it  had  lateral 
relationships  with  the  III  (German)  Korps  to  the  north  and  the  VII  (U.S.)  Corps  to  the 
south;  it  commanded  the  3rd  Armored  Division  (3AD),  the  8th  Infantry  Division  (8ID),  the 
11th  Armored  Cavalry  Regiment  (11ACR),  the  12th  Combat  Aviation  Group  (12CAG), 
and  numerous  brigade-sized  units. 

From  a  geographic  perspective,  V  Corps  was  responsible  for  approximately  37,500 
square  kilometers  of  real  estate  in  the  West  German  federal  state  of  Hesse. 

Information  flowed  vertically  and  horizontally  throughout  the  corps.  The  V  Corps 
main  and  rear  CPs  received  orders  and  information,  and  reported  to  the  CENTAG  CP;  the 
corps  support  command  received  information  from  and  reported  to  U.S.  Army  Europe 
(USAREUR)  headquarters;  the  V  Corps  CPs  transmitted  orders  and  information,  and 
received  reports  from  the  divisions,  the  armored  cavalry  regiment,  and  the  major  combat 
support  and  combat  service  support  units  in  the  corps  area  of  operations. 

The  V  Corps  headquarters  was  normally  divided  into  three  wartime  command  posts: 
the  TAC  CP,  the  main  CP,  and  the  rear  CP.  The  TAC  CP  consisted  of  four  armored 
command  post  vehicles,  one  platoon  from  the  corps  signal  brigade,  and  necessary 
supporting  vehicles.  The  TAC  CP  was  100  percent  mobile  and  was  capable  of  displacing 
every  12  to  24  hours.  The  main  CP  had  very  limited  mobility  and  required  considerable 


time  to  displace.  In  addition,  the  main  CP  had  prominent  physical  and  electronic  signatures 
that  were  very  difficult  to  reduce.  Like  the  main  CP,  the  rear  CP  had  limited  mobility, 
many  vehicles,  and  distinctive  signatures. 


Prior  to  the  implementation  of  the  dispersed  command  post  concept,  the  corps 
command  posts  were  the  main  CP,  the  rear  CP,  and  the  TAC  CP.  The  main  CP  consisted 
of  Communications,  Intelligence,  Tactical  Operations,  and  Air  Support  Operations  elements 
compressed  into  a  300-  by  300-meter  area.  The  critical  Tactical  Operations  Center  (TOC) 
consisted  of  the  Command,  G1  (Personnel  and  Administration),  G3  (Operations  and 
Plans),  G2  (Intelligence),  Engineer,  Weather,  Fire  Support,  and  Targeting  elements  in  a 
75-  by  75-meter  area.  During  the  same  period,  the  division  command  posts  were  the  main, 
rear,  division  TAC,  and  division  rear  CPs. 

Once  V  Corps  decided  to  pursue  the  DCP,  there  was  a  concerted  effort  to  realign 
physical  entities  and  structural  components.  The  main  CP  was  restructured  into  four 
modules  that  supported  four  battle  tasks.  The  new  modules  were  CTOC,  Plans,  FSE,  and 
Intel.  The  CTOC  was  similarly  restructured;  its  new  elements  became  Command,  G3 
Operations  (Opns),  G2  Opns,  G1  Opns,  G4  Opns,  Nuclear  Biological  Chemical  (NBC), 
Engineer,  and  Corps  Airspace  Management  Element  (CAME)  in  addition  to  liaison  officers 
from  subordinated  units,  adjacent  corps,  and  higher  headquarters. 

C .  ANALYSIS  OF  THE  V  CORPS  C2  PROCESS 

To  analyze  the  V  Corps  C2  process  using  MCES,  it  is  necessary  to  specify  the  corps 
mission  objectives,  the  commander's  tasks,  the  staff  functions,  and  the  functions  of  each 
module  in  the  three  command  posts. 


The  V  Corps  mission  objectives  can  be  defined  in  terms  of  four  battle  tasks: 
management  of  the  current  battle,  planning  the  future  battle,  planning  and  executing  the 


deep  attack,  and  sustainment  of  the  force  [Ref.  6:p.  2].  The  corps  mission  determines 
tasks  to  be  performed  and  initiates  the  military  decision  making  process,  which  proceeds  in 
four  phases:  (1)  collecting  information;  (2)  planning— to  include  an  estimate  of  the  situation, 
a  decision,  and  preparation  of  the  operations  plan;  (3)  issuing  orders;  and  (4)  supervising 
the  execution  of  issued  orders  [Ref.  3:pp.  3-36  -  3-46]. 


In  planning  his  battles,  the  corps  commander  analyzes  his  mission,  defines 
tasks,  establishes  intelligence  requirements  and  priorities,  organizes  the  corps  for  combat, 
assigns  missions  and  tasks  to  subordinate  commanders,  and  sets  priorities  for  combat, 
combat  support,  and  combat  service  support  units.  In  planning  all  operations,  the  corps 
commander  must  take  into  account  available  time  and  space  required  to  defeat  engaged 
enemy  forces  before  divisions  would  have  to  fight  follow-on  forces.  This  becomes  the 
"window"  against  which  system  performance  must  be  assessed.  As  the  plans  are  executed, 
the  commander  must  be  aggressive,  demanding,  and  personally  involved.  The  way  the 
corps  commander  generates  and  applies  combat  power  often  decides  the  outcome  of  battles 
and  campaigns.  (Appendix  E  specifies  the  tasks  performed  by  the  commander  in  the 
forward  deployed  corps.) 


The  commander  requires  assistance  to  assimilate  information  provided  through 
the  corps  command  and  control  system.  He  needs  support  to  filter  available  information, 
demand  more  when  the  picture  of  the  situation  is  not  complete,  analyze  pertinent  facts,  and 
communicate  decisions  to  the  many  people  that  must  thoroughly  understand  his  intent.  The 
staff  directs  and  coordinates  execution  of  the  commander's  intent  by  providing  the 
necessary  control  of  the  battle.  Appendix  C  specifies  those  tasks  completed  by  each  staff 


4  .  Command  Post  Functions 


The  three  wartime  CPs  of  the  V  Corps  Headquarters  were  identified  in  Section 
B.  The  orientation  of  the  TAC  CP  is  the  most  limited  of  the  three  command  posts.  With  its 
focus  on  the  close-in  battle,  the  TAC  CP  monitors  the  deep  and  rear  battles  only  for  their 
impact  on  Forward  Line  of  Own  Troops  (FLOT)  operations.  The  main  CP  focuses  on  the 
deep  battle.  Although  a  major  focus  of  the  rear  CP  is  to  sustain  operations  in  all  three 
batdes,  it  must  also  focus  on  fighting  the  rear  battle.  A  major  element  of  the  rear  CP  is  the 
rear  area  operations  center  (RAOC).  The  RAOC  manages  rear  area  protection,  commands 
and  controls  rear  area  combat  operations,  provides  current  battle  information  to  the  rear  CP, 
and  acts  as  the  alternate  main  CP.  Appendix  E  presents  the  functions  of  each  of  the  three  V 
Corps  command  posts. 

Each  module  of  the  corps  main  CP  is  organized  to  support  one  of  the  battle  tasks 
of  the  V  Corps  mission  objective  [Ref.  5:pp.  B-l-1  —  B-4-1]: 

1 .  The  CTOC  monitors  the  current  situation  in  the  corps  sector  and  adjacent  corps 
sectors.  It  allocates  resources  to  major  subordinated  units  in  order  to  influence  the 
current  battle.  The  CTOC  executes  operations  plans  and  operations  orders.  It 
ensures  the  availability  of  current  battle  information  to  all  elements  of  the  corps  C2 
structure  with  emphasis  on  decision  making  information  required  by  the  commander. 

2.  The  FSE  coordinates  the  attack  of  deep  targets.  The  FSE  also  executes  the  attack  of 
deep  targets  with  air  force  support,  organic  missile  artillery,  and  electronic  warfare 
assets. 

3 .  The  Plans  module  translates  the  commander's  guidance  into  appropriate  priorities  for 
the  intelligence  effort,  target  development,  the  deep  attack,  and  resource  allocations. 
The  Plans  module  also  incorporates  priorities  and  guidance  into  operations  plans. 

4.  The  Intelligence  module  provides  timely  and  reliable  information  on  threat 
dispositions,  capabilities,  activities,  and  intentions.  It  tasks  the  intelligence 
collection  assets  to  support  operations  plans.  This  module  disseminates  periodic 
intelligence  reports  to  other  modules,  subordinate  units,  and  higher  headquarters. 
Finally,  it  nominates  appropriate  targets  to  the  FSE. 
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D.  V  CORPS  C2  SYSTEM  ARCHITECTURE 


The  V  Corps  C2  system  architecture  is  described  by  an  integrated  set  of  systems 
whose  elements  and  functions  are  coherently  related.  The  corps  physical  entities  and 
structural  components  (described  in  Section  B)  are  mapped  to  the  C2  process  definition 
(Section  C).  Figure  2.1  graphically  represents  this  integration  for  the  consolidated  main 
command  post.  To  construct  the  V  Corps  system  architecture,  it  was  necessary  to  map 
from  the  corps  battle  tasks-the  highest  level  of  this  architecture-down  to  the  module 
elements  (or  sub-elements)  that  perform  the  specific  staff  functions.  (These  functions  are 
subdivided  into  specific  tasks  for  each  staff  section  or  element  in  Appendix  C.)  First,  the 
corps  battle  tasks  were  mapped  to  the  corps  CP  functions.  Next,  the  CP  functions  were 
decomposed  into  specific  functions  for  each  module.  Then  these  specific  functions  were 
mapped  to  the  module  elements— or  sub-elements— which  perform  them.  Finally,  the 
functions  were  mapped  to  the  appropriate  task  of  the  particular  element.  Table  1  illustrates 
this  mapping  from  one  of  the  four  corps  battle  tasks,  "Manage  the  current  battle,"  through 
one  of  the  many  CTOC  functions,  down  to  the  specific  tasks  for  each  CTOC  element,  e.g., 
G3  Operations  is  tasked  to  "Monitor  the  current  situation." 

After  these  architectural  relationships  were  identified,  the  MCES  provided  guidance 
for  both  qualitative  and  quantitative  measures  based  upon  the  specific  form  of  data 
generation  selected. 

E.  SPECIFICATION  OF  MEASURES 

1 .  Introduction 

The  purpose  of  this  section  is  to  identify,  develop,  and  select  measures  that  gauge  the 
V  Corps  C2  system's  response  to  directing  forces.  These  measures  will  provide  the  values 
used  to  assess  performance  and  effectiveness  by  comparison-both  at  any  point  in  time,  and 


Fig.  2.1  Integration  of  System  Elements  and  Functions  in  the  Consolidated  Main  Command  Post 


Table  2.3  Mapping  the  C2  Process  for  a  Single  Corps  Battle  Task 


as  the  underlying  architecture  of  the  C2  system  changes  from  the  V  Corps  baseline  through 
the  three  operational  capabilities.  The  measures  are  selected  to  relate  directly  to  the 
architectural  and  operational  issues  posed  in  this  analysis.  It  should  be  noted  that  additional 
measures  might  be  useful  for  addressing  another  set  of  issues. 

Three  problems  were  identified  in  Chapter  I.  The  first  asks  whether  SPADS 
supported  the  V  Corps  commander  as  he  exercised  command  and  control  of  his  combat 
assets  to  meet  the  mission  objectives  in  the  four  corps  battle  tasks.  The  second  asks 
whether  the  V  Corps  dispersed  command  post  concept  actually  enhanced  command 
survivability.  The  final  problem  questions  whether  the  SPADS  evolutionary  development 
approach  affected  C2  force  effectiveness  throughout  the  three  OCs. 

2.  Problem  1 

Four  measures  of  performance  (MOPs)  and  two  measures  of  effectiveness 
(MOEs)  were  initially  selected  for  the  first  problem.  The  MOPs  were:  (1)  flexibility,  (2) 
availability,  (3)  interoperability,  and  (4)  responsiveness.  These  MOPs  specified 
performance  inside  the  C2  system  using  the  criteria  "yes-it-works/no-it-doesn't-work” 
[Ref.  2:p.  97],  The  MOEs  were:  (1)  timeliness  and  (2)  capacity;  these  address  structural 
components  and  physical  entities  respectively.  A  third  MOE  was  developed  as  a  function 
of  flexibility,  availability,  interoperability,  and  responsiveness  (FAIR)  to  address  the  C2 
process.  Finally,  a  measure  of  force  effectiveness  (MOFE),  addressing  C2  mission 
orientation  (xMOxi),  was  defined  as  a  function  of  the  C2  process,  structural  components, 
and  physical  entities.  Table  2  defines  the  measures  selected  for  this  problem. 


In  the  second  problem,  the  three  MOPs  selected  were:  (1)  dispersion,  (2) 
redundancy,  and  (3)  continuity  of  operations  [Ref.  6:pp.  1,  B-l  -  B-2].  The  issue  of 
command  survivability  (^CSji)  was  addressed  by  defining  an  MOE  that  was  a  function  of 
the  three  MOPs.  The  selected  measures  are  defined  in  Table  3. 

4.  Pnfl.bie.m-J 

The  third  problem  was  more  challenging.  SPADS  could  not  evolve  as  a  C2 
force  effectiveness  system  based  upon  operational  lessons  learned  unless  it:  (1)  provided 
the  commander,  and  his  staff,  with  the  ability  to  exercise  command  and  control  of  his 
combat  assets  to  meet  overall  mission  objectives;  and  (2)  demonstrated  that  the  dispersed 
command  post  concept  enhanced  command  survivability.  Therefore,  an  MOFE  related  to 
C2  force  effectiveness  (C2/FE)  was  defined  in  terms  of  C2  mission  orientation  in  command 
survivability.  C2  force  effectiveness  is  defined  in  Table  4. 

F.  DATA  GENERATION 

Appropriate  data  for  the  measures  specified  in  Section  E  were  generated  from  after 
action  reports,  external  evaluations,  and  operational  experience.  Data  were  generated 
during  numerous  field  training  and  command  post  exercises  throughout  the  three  OCs. 
These  exercises  closely  followed  the  general  defense  plans  used  by  V  Corps  to  train  for 
combat  operations.  In  each  exercise,  the  C2  system  was  exercised  by  highly  trained  staff 
officers  and  NCOs  who  used  the  system  as  they  would  in  a  wartime  environment. 

The  worksheet  used  to  collect  the  data  is  shown  in  Table  5.  This  format  was  used  for 
evaluating  the  three  operational  capabilities;  the  worksheet  results  are  shown  in  Sections  F 
and  G  of  Chapters  III,  IV,  and  V.  The  corps  baseline  was  evaluated  using  operational 
experience  and  doctrinal  publications.  After  action  reports  were  the  principal  source  of  data 
generation  for  the  three  operational  capability  cycles. 


TABLE  4 

MEASURE  SELECTED  FOR  THE  THIRD  PROBLEM 


Type  Name/Formula  Description 

MOFE  C2  Force  Effectiveness,  =  f  (XMOTi,  XCSTi) 

C2/FE,  at  Ti 

Command  and  control  force  effectiveness  of  the  V  Corps 
Dispersed  Command  Post  can  be  interpreted,  at  the 
conclusion  of  an  operational  capability,  as  the  summation 
of  the  values  for  command  and  control  mission  orientation, 
XMOTi,  and  command  survivability,  XCSTi. 


Each  measure  listed  in  Tables  1  through  3  was  evaluated  as  a  binary  condition.  The 
measure  received  a  single,  unweighted  digit  if  it  met  the  condition  "the  description  of  the 
measure  in  the  table  is  true."  Using  the  worksheet  shown  in  Table  5,  each  module  present 
during  that  exercise  was  evaluated  for  every  measure.  The  results  on  the  worksheet  were 
columns  consisting  of  ones  and  zeroes.  Every  summed  measure  (e.g.^FAIR,  XMOTi,  and 
XCSTi)  received  a  cumulative,  unweighted  score  on  the  worksheet.  The  final  measure, 
C2/FE,  was  computed  using  the  description  in  Table  4,  and  the  result  was  placed  on  the 
worksheet.  The  results  of  these  evaluations  are  displayed  in  tables  in  Section  F  of  Chapters 
III,  IV,  and  V.  In  addition,  the  means  of  each  measure  for  the  entire  operational  capability 
cycle  are  displayed  in  figures  immediately  following  the  tables. 

Two  indicators  of  bias  in  the  underlying  data  must  be  discussed.  The  first  is  missing 
data;  in  certain  after  action  reports  specific  activities  are  absent  and  cannot  be  inferred.  The 
second  is  observer  unreliability;  there  are  clear  differences  in  both  style  and  content 
between  different  writers  of  the  after  action  reports.  [Ref.  2:pp.  57-58] 


TABLE  5 

DATA  GENERATION  WORKSHEET 


Baseline _ OC1 _ OC2 _ OC3  Exercise: 


Main  CP  TAC  CP  REAR  CP 

Problem  1: 

FAIR 

•  Flexibility 

•  Availability 

•  Interoperability 

•  Linkability 

•  Usability 

•  Responsiveness 

•  Hardware 

•  Software 

TIMELINESS 
CAPACITY 
XMOTi 
Problem  2: 

DISPERSION 

REDUNDANCY 

•  Key  Info  Elements 

•  Skilled  Personnel 

CONTINUITY 

•  Reliability 

•  Transportability 


XCSTi 
Problem  3: 


CTOC  PLANS  FSE  INTEL 


C2/FE 


G .  AGGREGATION  AND  INTERPRETATION  OF  MEASURES 

1 .  General 

Problem  1  addresses  command  and  control  as  a  measure  of  force  effectiveness 
derived  as  a  linear  function  of  the  values  for: 

1 .  Mission  orientation— 'he  C2  process— which  itself  is  interpreted  as  the  summation  of 
the  values  derived  for  flexibility,  availability,  interoperability,  and  responsiveness 
(FAIR) 

2.  Structural  components  interpreted  as  a  measure  of  timeliness 

3 .  Physical  entities  as  a  function  of  capacity 

Problem  2  addresses  survivability  as  a  measure  of  effectiveness  derived  for 
dispersion  and  redundancy. 

In  Problem  3,  the  measure  of  command  and  control  force  effectiveness  is  derived 
from  the  linear  aggregation  of  the  value  derived  for  the  MOFE  from  Problem  1  and  the 
value  of  the  MOE  from  Problem  2.  The  command  and  control  force  effectiveness  of  the  V 
Corps  CP  was  measured,  at  the  conclusion  of  an  operational  capability,  by  adding  the 
values  derived  for  the  evaluation  of:  (1)  the  interaction  of  mission  orientation,  structure, 
and  physical  entities  in  Problem  1;  and  (2)  survivability  in  Problem  2. 

As  indicated  in  Section  E,  several  of  the  measures  are  functions  of  other,  lower- 
level  measures.  The  actual  algorithm  for  any  given  application  must  be  validated  and 
verified  against  real  world  or  other  applicable  observations.  For  the  purpose  of  this  thesis, 
the  values  of  such  proposed  measures  as  FAIR,  xMOxi,  xCSxi,  and  C2/FE  are  defined  as 
the  weighted  sum  of  the  constituent  MOPs.  However,  other  weights  are  arbitrary  and  the 
relationships  could  be  linear  or  non-linear,  relational  or  multiplicative.  Only  replication, 
conferencing  and/or  synthesis  of  expert  opinion,  and  external  validation  can  present  more 
certainty  on  the  assessment  of  factors  and  their  aggregations.  The  major  advantage  of  this 


thesis  is  that  it  broaches  the  subject  and  presents  a  strawman  for  consideration  by  the 
analytical  community.2 


In  evaluating  the  V  Corps  baseline  it  would  be  counterproductive  to  attempt  to 
apply  the  quantitative  standards  used  for  the  three  operational  capabilities.  The  baseline 
condition  requires  a  subjective  evaluation  based  upon  the  appropriate  doctrinal  publications 
and  operational  experience. 

a.  Problem  1 

Before  implementing  the  DCP  concept,  the  commander  and  his  staff  were 
able  to  exercise  command  and  control  to  meet  mission  objectives.  Certainly  the  staff  was  as 
flexible,  available,  and  responsive  as  their  procedures  and  communications  support 
allowed.  On  the  other  hand,  traditional  command  posts  had  no  links  to  other  C2  systems, 
and  the  staff  received  all  of  their  information  by  hard  copy  message,  facsimile  or  verbal 
report.  Although  staff  members  may  have  prided  themselves  on  their  efficiency,  they  had 
no  way  to  speed  up  the  flow  of  critical  information  from  its  source(s)  to  the  commander. 
In  a  similar  manner,  the  staff  had  only  a  limited  capacity  to  handle  data,  reports,  or 
functions  during  a  given  period;  they  were  often  overcome  by  events  during  operations. 

In  analyzing  the  manual  C2  process,  it  becomes  obvious  that  technology  would 
be  hard  pressed  to  meet  the  staffs  contribution  to  the  C2  functionality.  However,  the 
greatest  potential  of  automated  C2  systems  lies  in  improving  the  physical  entities'  and 
structural  components'  contributions  to  overall  C2  mission  orientation. 


2  Conversation  between  Dr.  Ricki  Sweet,  Sweet  Associates,  Ltd,  and  the  author  in 
San  Jose,  California,  1 1  March  1988. 


b .  Problem  2 

The  V  Corps  commander  wanted  to  employ  the  DCP  concept  in  1981  to 
dramatically  increase  command  survivability.  (Appendix  E  describes  the  numerous  threats 
to  the  corps  command  posts.)  It  was  obvious  at  that  time  that  merely  dispersing  the 
modules  of  the  main  CP  would  not  be  enough.  A  plan  was  required  that  would  support 
continuity  of  operations  with  redundancy  of  functional  staff  personnel  and  key  information. 
Before  it  implemented  the  DCP  concept,  V  Corps  had  no  way  to  consistently  achieve 
command  survivability. 

c .  Problem  3 

The  third  problem  cannot  be  fairly  addressed  with  regards  to  V  Corps'  use 
of  a  consolidated  main  CP.  Before  dispersion,  V  Corps  recognized  the  threats  to  command 
survivability  and  effectiveness  but  was  constrained  by  Army  doctrine  and  materiel  in  its 
efforts  to  improve  the  situation. 


III.  OPERATIONAL  CAPABILITY  1 


A.  PROBLEM  DEFINITION 

The  Defense  Nuclear  Agency  started  the  first  operational  capability  in  September  1981 
with  a  microcomputer  workstation  demonstration  during  REFORGER  81.  The  exploratory 
development  program  had  proceeded  from  concept  formulation  to  the  initial  design  and 
demonstration  phase.  Designs  and  capabilities  were  tested  and  refined  during  the  four 
exercises  of  Operational  Capability  1  (OC1):  REFORGER  81,  Able  Archer  81,  Crested 
Eagle  82,  and  Caravan  Guard  III. 

This  section  addresses  four  issues  central  to  problem  formulation: 

1 .  What  were  the  stated  requirements  of  OC 1  ? 

2 .  What  tasks  from  the  statement  of  work  (SOW)  supported  OC1? 

3 .  What  design  principles,  mandated  by  DNA,  guided  the  development? 

4.  What  were  the  goals  of  each  exercise? 

Figure  3.1  shows  the  five  requirements  of  OC1  along  a  month  by  month  timeline 
consisting  of  17  months.  The  dates  of  the  four  exercises  during  OC1  are  marked  by 
and  are  listed  below  the  central  rectangle.  The  objectives  of  OC1,  based  upon  the  re¬ 
quirements  and  the  technological  characteristics,  are  shown  to  the  right. 

1 .  Requirements  for  PCI 

OC1  objectives  consisted  of:  (1)  the  effective  implementation  and  operation  of 
nine  dispersed  V  Corps  command  post  modules,  (2)  distributed  processing  through  an 
automated  communications  gateway,  (3)  automated  briefing  files,  (4)  an  electronic  mail 
system,  and  (5)  initiation  of  a  divisional  SPADS  system. 
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a.  V  Corps  DCP  Concept 


The  DCP  experimentation  program  was  conducted  under  Contract 
DNA001-81-C-02771,  awarded  in  August  1981.  The  purpose  of  the  contract  was  to  allow 
the  earliest  possible  testing  of  the  V  Corps  DCP  concept.  To  accomplish  rapid  fielding, 
DNA  employed  non-developmental  items  (NDI)  which  took  advantage  of  off-the-shelf 
technology. 

DNA  established  a  testbed  at  V  Corps;  its  objective  was  to  develop  an 
automated  command  and  control  system  instrumental  to  testing  and  evaluating  the  dispersed 
command  post  concept.  The  primary  test  objective — evaluating  the  effectiveness  of  the 
DCP  concept — would  be  accomplished  while  responding  to  the  V  Corps  request  of  May 
1981  [Ref.  4:pp.  1-2].  What  remained  was  to  design  an  automated  C2  system  which  could 
be  fielded  rapidly  to  support  the  test  and  evaluation  of  the  DCP  concept. 

DNA  postulated  a  DCP  model  which  called  for  the  fragmentation  of  the 
corps  main  command  post,  particularly  the  Tactical  Operations  Center  (TOC),  into  several 
modules  and  for  dispersal  of  these  modules  with  ten  kilometers  or  more  between  them. 
DNA  envisioned  that  the  concept  would  be  extended  throughout  the  corps  operational  area 
to  its  supporting  CPs  such  as  the  Rear  Area  Operations  Center  (RAOC)  and  the  tactical 
command  post  (TAC  CP),  as  well  as  to  combat  divisions  and  armored  cavalry  regiment. 
After  action  or  lessons  learned  reports  would  be  prepared  for  each  exercise  conducted 
during  this  operational  capability  period  (August  1981  through  December  1983).  [Ref. 
8:pp.  9-13] 


1  Interview  between  R.  Laird,  Lieutenant  Colonel,  USA,  Defense  Nuclear  Agency, 
Alexandria,  Virginia,  and  the  author,  17-18  December  1987. 


Since  requirements  were  expected  to  be  refined  as  the  system  was  fielded 
and  experimentation  proceeded,  an  evolutionary  development  approach  and  modular  design 
philosophy  was  adopted  [Ref.  8:pp.  75-9],  This  would  allow  early  fielding  of  basic 
capabilities  and  subsequent  DCP  experiments,  while  providing  the  flexibility  to  add  greater 
and  more  finely  tuned  capabilities  throughout  the  test  period.  It  would  also  allow  the 
experiment  to  proceed  without  waiting  for  the  availability  of  microcomputer  and  peripheral 
equipment  based  on  emerging  technologies,  and  it  would  maintain  the  ability  to  insert 
advanced  capabilities  when  those  technologies  matured  and  new  equipment  was  available  in 
the  commercial  marketplace. 

b.  Distributed  Processing 

The  V  Corps  automated  prototype  was  required  to  support  a  distributed 
processing  configuration  consisting  of  a  network  of  microcomputer  workstations.  (This 
definition  contrasted  with  traditional  automated  systems  composed  of  one  central  processor 
and  dependent  terminals  that  are  incapable  of  independent  processing.)  A  local  area 
network  (LAN)  would  connect  workstations  within  each  V  Corps  command  post  module. 
A  communications  gateway  would  provide  network  connectivity  via  Army  voice 
communications  channels.  The  supporting  architecture  would  include  a  replicated  data  base 
at  each  module,  thus  providing  each  cell  with  the  same  information.  The  communications 
links  between  and  among  the  modules  were  to  be  provided  by  the  Tactical  Area  Switching 
System  (TASS).  The  capabilities  at  each  work  station  would  eventually  include  word 
processing,  electronic  mail,  graphics  and  overlays,  a  relational  database  management 
system,  map  and  photo  correlation,  spreadsheet  models,  and  functional  area  algorithms. 
[Ref.  8:pp.  36-38] 
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c.  Automated  Briefing 


An  automated  briefing  capability  was  specified  to  enable  any  staff  officer  to 
create  briefing  slides  and  text  at  a  workstation.  In  order  to  minimize  communication 
requirements  when  transmitting  these  briefing  slides  to  other  modules,  graphics 
information  that  was  not  expected  to  change  would  be  created  and  stored  as  a  background 
slide.  Information  that  was  expected  to  change  would  be  created,  stored,  transmitted,  and 
presented  as  an  overlay.  All  slides  would  be  stored  on  a  module's  mass  storage  station. 
New  and  updated  slides  from  other  modules  were  to  be  received  through  the 
communications  gateway  and  stored  at  the  mass  Stonge  station.  A  printing  capability  for 
text  and  graphics  would  be  provided.  [Ref.  8:p.  26] 
d .  Electronic  Mail 

An  electronic  mail  system  (EMS)  was  required  to  transmit  messages 
between  the  workstations  in  the  dispersed  modules  of  the  DCP.  The  EMS  would  be  able  to 
handle  standard  text  messages  as  well  as  non-text  material  such  as  graphics.  Mail  would 
be  prepared  by  the  operator  and  would  be  sent  to  any  other  user  through  that  module's 
gateway.  [Ref.  8:p.  27] 

e  .  8ID  DCP  Concept 

The  8th  Infantry  Division  would  be  employed  as  a  smaller  and  more  tactical 
version  of  the  V  Corps  testbed.  The  requirement  was  to  provide  dispersal  plus 
effectiveness  for  the  small,  highly  mobile  elements  of  the  division  command  posts. 

2 .  Tasks  from  the  Statement  of  Work 
a.  Task  1:  V  Corps  Support 

This  task  provided  for  support  to  V  Corps  during  Exercises  REFORGER 
81  Able  Archer  81,  and  Crested  Eagle  82.  The  first  responsibility  was  to  ensure  that  the 
current  procedures,  SOPs,  reports,  and  information  flow  were  examined  before  proceeding 


with  the  project.  The  second  responsibility  was  to  gather  specific  requirements  from  the 
principal  staff  sections  so  that  applications  and  data  bases  could  be  developed. 

b.  Task  2:  DCP  Concepts 

The  purpose  of  this  task  was  to  identify  and  test  feasible  information 
exchange  concepts  for  the  DCP  project.  For  communications  networking  within  the 
module,  different  commercial  LANs  would  be  tested  and  one  selected  to  support  SPADS. 
For  communications  networking  between  modules,  gateway  concepts  would  be  examined 
and  tested  to  determine  the  baseline  for  developing  a  communications  gateway  that  could 
support  the  DCP  concept.  All  networking  tests  would  be  conducted  in  CONUS. 

c.  Task  3:  Caravan  Guard  Support 

This  task  specified  various  tasks  to  support  the  V  Corps  DCP  concept  in 
Germany.  The  staff  operators,  NCOs,  and  action  officers  would  be  trained  on  how  to  use 
SPADS  to  support  V  Corps  DCP  operations.  An  SOP  would  be  developed  for  dispersed 
operations  that  used  microcomputer  equipment.  Communications  gateway  software 
development  would  proceed  to  support  four  dispersed  CP  locations. 

d.  Task  4:  PTT  Management  Interfaces/Procedures 

This  task  required  that  the  West  German  national  telecommunications 
system  (the  Deutsches  Bundespost,  or  DBP)  be  examined  to  determine  how  it  could 
support  SPADS.  The  first  test  would  determine  whether  gateways  would  be  able  to 
communicate  over  the  standard  DBP  phone  lines.  This  would  be  followed  by  tests  to 
determine  if  special  "conditioned"  data  links  would  be  required  to  effectively  use  the  DBP. 

e.  Task  5:  V  Corps/8ID  C2  Doctrine  Evaluation 

This  task  would  develop  a  capability  to  evaluate,  through  evolutionary 
testing,  the  effectiveness  of  the  requirements  for  emerging  Army  doctrine  on  dispersed  Field 
C2.  The  principal  effort  would  be  to  develop  a  testbed  to  evaluate  an  information 


distribution  and  processing  system  between  the  corp;,  division,  and  corps/division 
command  elements.  The  final  test  plan  would  provide  a  basis  for  documenting  and 
evaluating  the  results  of  the  theoretical  efforts  related  to  internal  corps  and  division  C2 
operations. 

Task  5  carried  the  V  Corps  DCP  demonstration  through  the  fall  of  1982.  In 
January  1982  the  Army  Communicative  Technology  Office  (ACTO)  provided  $536,000  (of 
the  $1.2  million  required  for  SPADS  up  to  that  date)  to  purchase  equipment  for  a  "full-up" 
demonstration.2  The  pacing  items  would  be  software  development  and  assimilation  of  the 
equipment  by  V  Corps. 

f.  Task  8:  SID  AirLand  Battle  DCP  Program 
The  purpose  of  this  task  was  to  develop  a  division-level  SPADS  program  that 
would  eventually  be  integrated  into  the  V  Corps  DCP  program.  The  sub-tasks  were  to:  (1) 
deliver  a  division  level  SPADS  system,  (2)  conduct  user  training  for  the  8ID,  (3)  support 
the  user  test  of  the  system  in  garrison,  and  (4)  support  user  tests  of  the  SPADS  system  in 
the  field  environment.  This  task  specifically  required  support  for  8ID  to  develop  and 
validate  the  operating  procedures  as  well  as  to  develop  and  test  its  own  field  procedures. 
The  TRADOC  Combined  Arms  Center  contributed  $480,000  in  March  1982  to  support  the 
8 ED  SPADS  development.3 

3  .  DNA  Design  Principles 

The  DNA  evaluated  necessary  automated  command  and  control  requirements 
from  the  perspective  of  battlefield  information  needs  and  the  capabilities  available  from 
commercial  NDI  technology.  That  analysis  produced  seven  design  principles  and  an  ap- 


proach  to  evaluating  the  DCP  concept.  This  section  addresses  those  design  principles  that 
were  incorporated  in  OC1.  [Ref.  8:p.  16] 

a.  Maintain  a  Common  Battlefield  Perception 

Every  module  in  the  DCP  had  to  share  a  common  perception  of  the 
battlefield  situation  if  operations  were  to  be  effectively  planned,  executed,  and  controlled. 
This  meant  that  every  module  must  have  the  same  information.  A  key  design  concept  of 
the  DCP  automated  C2  system  was  replication  of  the  essential  parts  of  the  current  situation 
information  available  at  every  module.  Each  module  was  responsible  for  maintaining  a 
portion  of  the  Current  Situation  data  base  and  transmitting  updates  to  all  other  modules. 
The  common  perception  concept  would  [Ref.  8:pp.  17-18]: 

1 .  Allow  the  commander  immediate  access  to  critical  data  on  the  total  situation  at  any 
module  and  at  any  time 

2.  Provide  a  common  perception  of  all  aspects  of  unit  status  to  all  corps  modules 

3 .  Provide  redundancy  necessary  for  continuity  of  operations 

4.  Be  less  dependent  on  the  communications  system  than  remote  query  to  a  central  data 
base 

5.  Relieve  the  staff  from  the  necessity  of  requesting  critical  information  from  other 
modules 

b.  Minimize  Data  Transmission 

Limited  Army  tactical  communications  capabilities  within  the  corps  required 
a  conservative  data  update  philosophy  to  reduce  the  heavy  burden  that  data,  particularly 
data  for  graphics  displays,  could  impose.  The  principle  adopted  for  the  DCP  would  be  to 
transmit  only  overlay  data  through  electrical  means;  backgrounds  such  as  maps  or  chart 
matrices  would  be  pre-positioned  at  all  modules  or  delivered  by  courier.  Only  the  data  that 
changed  (i.e.,  the  overlays)  would  be  sent  through  the  communications  network.  [Ref. 


c.  Maintain  Continuity  of  Operations 

The  critical  requirement  for  continuity  of  operations  influenced  the  DCP 
equipment  configuration  and  recommended  employment  concept.  The  basic  principle  was 
to  design  for  graceful  degradation.  If  part  of  the  system  failed,  the  remaining  components 
should  continue  to  operate.  Specific  design  features  were  [Ref.  8:p  21]: 

1 .  Distributed,  intelligent  workstations  would  be  selected  rather  than  the  traditional,  less 
capable  terminals  serviced  by  a  multi-user  central  computer 

2.  A  graphics  plotter  would  be  employed  at  selected  modules  to  periodically  provide 
backup  acetate  overlays  of  the  force  status  and  enemy  situation;  this  duplication 
would  ensure  that  critical  map  overlays  would  be  available  even  if  the  system  totally 
failed 

3.  A  medium-speed  printer  would  provide  hard  copy  text  and  ensure  that  essential 
records  were  kept  in  the  event  of  a  major  system  failure 

4.  A  direct  communications  interface  between  selected  workstations  at  distant  modules 
would  provide  backup  communications  in  the  event  of  a  gateway  failure  or  during 
peak  traffic  backlogs 

5 .  The  data  bases  and  current  situation  briefings  would  be  duplicated  at  each  module; 
each  module  would  contain  the  data  necessary  to  reconstitute  the  functions  of  a 
destroyed  module 

d.  Computational  Support 

Each  module  would  have  its  own  set  of  requirements  for  analysis,  e.g., 
generating  spreadsheets  on  personnel  and  equipment  needs,  or  for  creating  local  data  bases. 
The  system  would  be  designed  to  provide  the  capability  of  executing  commercial  software 
programs  and  creating  local  programs  to  meet  the  needs  of  each  module.  This  principle 
would  ensure  maximum  utilization  of  existing  programs  and  enable  individual  staff 
elements  to  develop  software  tailored  to  their  specific  needs.  [Ref.  8:p.  21] 

e.  Provide  a  Rugged,  Low-cost  System 

The  DCP  program  was  required  to  use  commercial  equipment  modified  for 
field  use.  The  time  to  develop  and  field  the  system  was  thus  expected  to  be  one-fifth  of  the 
normal  development  time  because  of  the  use  of  off-the-shelf  commercial  products.  This 
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would  also  maintain  a  lower  cost  than  conventionally  developed  hardware  and  software 
programs. 

It  would  be  necessary  to  take  some  steps,  without  attempting  full 
militarization,  to  ensure  that  the  hardware  package  would  perform  effectively  in  the  field. 
The  microcomputers  would  be  modified  to  provide  simple  connections  between  the 
computer  and  other  devices  in  the  system.  This  would  alleviate  the  need  for  an  operator  to 
open  the  microcomputer  case  to  make  connections  in  the  field  environment.  Special 
transport  cases  would  be  designed  to  protect  the  equipment  from  exposure  and  during 
transportation.  The  rigid  cases  would  provide  the  structural  framework  for  the  operating 
workstations.  [Ref.  8:p.  21] 

4 .  Exercise  Objectives  Dnrinu  OC1 

The  objective  for  Exercise  REFORGER  81  was  to  demonstrate  the 
capabilities  of  a  microcomputer  workstation  in  the  corps  main  command  post.  The 
objective  of  the  next  exercise.  Able  Archer  81,  was  to  demonstrate  that  files  could  be 
transferred  over  Army  tactical  communications  between  microcomputer  workstations  in 
different  modules.  The  two  objectives  for  Exercise  Crested  Eagle  82  were  to:  (1)  conduct  a 
test  that  demonstrated  that  bulk-encrypted  data  could  be  transferred  between  two  modules 
using  TASS,  and  (2)  to  add  the  8ID  to  the  DCP  experiment.  The  five  objectives  of  the  last 
exercise,  Caravan  Guard  III — the  most  significant  of  OC1 — were  to:  (1)  simulate  the 
dispersal  of  nine  modules,  (2)  use  the  automated  communications  gateway  station  (CGS) 
over  TASS,  (3)  connect  the  8ID  main  CP  to  the  corps  SPADS  system,  (4)  disperse  the 
TAC  CP  up  to  45  kilometers  from  the  main  CP,  and  (5)  implement  the  Current  Situation 
and  Electronic  Mail  System  (EMS)  software.  Table  6  presents  the  exercises  and  objectives 
ofOCl.  [Ref.  8:pp.  26-281 
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TABLE  6 

OVERVIEW  OF  OPERATIONAL  CAPABILITY  1 


Primary  Objective(s)  Date 


Contract  Award 

Aug. 

1981 

Exercise  REFORGER  81 

Sept . 

1981 

Demonstrate  microcomputer  workstation 

Exercise  Able  Archer  8 1 

Jan. 

1982 

Demonstrate  file  transfer 

Exercise  Crested  Eagle  82 

March 

1982 

Transfer  bulk-encrypted  data  between  two  modules 

Exercise  Caravan  Guard  m 

June 

1982 

Disperse  nine  CP  modules 

Automate  communications  gateway  over  TASS 

Add  8th  Infantry  Division  to  experiment 

Disperse  CP  modules  up  to  45  km  apart 

Test  Current  Situation  and  Electronic  Mail  System 

B  .  BOUNDING  THE  C2  SYSTEM 

This  section  addresses  the  bounds  of  the  SPADS  system  in  terms  of  physical  entities 
and  structure  at  three  distinct  levels.  First,  the  workstation  bounds  the  hardware  and 
software  with  which  an  operator  interacts.  Next,  the  module  level  describes  the  SPADS 
entities  and  structure  within  the  confines  of  one  modular  command  post.  Finally,  the 
network  level  defines  the  SPADS  system  within  the  geographical  and  hierarchical  bounds 
that  interconnect  the  modules. 

1 .  Workstation  Level  Bounding 
a.  Hardware 

The  only  hardware  that  the  staff  officer  or  SPADS  operator  interacted  with 
personally  was  the  staff  duty  station  (SDS).  The  SDS  was  contained  in  two  ruggedized 
cases  that  stacked  one  atop  another  to  provide  an  operational  workstation.  The  upper  case 


contained  two  monitors.  The  lower  case  contained  an  Apple  4  11+  microcomputer,  two 
floppy  diskette  drives,  and  a  power  control  panel.  The  Apple  11+  microcomputer  was  the 
central  focus  of  the  SDS.  Inside  the  microcomputer  case  were  numerous  interface  cards  to 
control  the  disk  drives,  provide  accurate  time,  interface  with  the  printer,  provide  a  serial 
port  for  a  modem,  and  provide  extra  random  access  memory  (RAM).  The  operator  typed 
all  commands  at  the  keyboard.  Two  5-1/4-inch  floppy  diskette  drives  were  attached  to  the 
backplane  of  the  microcomputer.  These  drives  could  be  used  to  store  and  input  data  or  to 
execute  commercial  software  programs.  On  the  left  side  of  the  upper  SDS  case  a  black  and 
green  (B&G)  monitor  provided  for  text  display.  To  the  right,  an  analog  color  monitor 
displayed  briefing  slides.  Table  7  presents  an  overview  of  the  SDS  hardware.  [Ref.  8:pp. 
38-41] 

b.  Software 

All  SPADS  software  functions  were  performed  at  the  SDS  by  the  operator. 
The  two  required  functions  implemented  during  OC1  were  Current  Situation  and  Electronic 
Mail  System  (EMS).  Current  Situation  provided  an  immediate  overview  of  the  battle 
situation,  including  the  status  of  units.  It  was  dependent  upon  the  Briefing  package,  which 
provided  the  ability  to  create  and  present  briefings.  EMS  allowed  the  operator  to  send  or 
receive  standard  text  messages,  data,  graphics,  and  computer  code.  One  flexible  SPADS 
software  package  was  Local  Program  Execution,  which  allowed  the  operator  to  execute 
programs  locally,  e.g.,  special  programs  to  assess  personnel  needs,  logistics  support,  and 
other  staff  tasks.  [Ref.  8:pp.  44,  48] 


4  Apple  is  a  registered  trademark  of  Apple  Computer,  Inc.,  Cupertino,  California. 


TABLE  7 

STAFF  DUTY  STATION  HARDWARE 


Microcomputer 

Apple  H+ 

Processor 

Synertek  MOS  6502,  8-bit  data 

Memory 

48K  (64K  with  Slot  0  Card) 

Graphics 

5x7  Dot  matrix  for  280  x  192  array 

Monitors 

Analog  Color  Display 

Black  and  Green  Display 

Keyboard 

52-key  typewriter  keyboard  (attached) 

8  Slot  Expandable  Bus 

Power  supply 

120V/50-60  Hz  power 

Floppy  Drive  (2) 

5-1/4-inch,  140  Kbytes 

The  Current  Situation  package  preceded  any  common  data  base  function  in 
SPADS.  Current  Situation  allowed  text  and  slide  displays  of  any  data  that  the  staff  wished 
to  include.  Current  Situation  data  consisted  of  input  from  local  users  plus  information 
obtained  from  staff  sections  in  other  modules.  All  information  generated  or  received  was 
stored  on  the  module's  mass  storage  station.  All  locally  generated  slides  and  text  used  in 
Current  Situation  were  transmitted  through  the  CGS  to  the  other  command  post  modules. 
Any  operator  was  able  to  obtain  a  hard  copy  printout  of  the  text  and  graphics  information 
from  the  shared  output  station.  [Ref.  8:p.  48] 

The  operator  was  able  to  create  briefing  slides  and  text  at  the  SDS.  In  order 
to  minimize  communications  requirements  when  transmitting  slides  to  other  modules, 
graphics  information  that  was  not  expected  to  change  from  one  slide  to  another  was  created 
as  a  background  slide.  Information  that  was  expected  to  change  was  presented  as  an 
overlay.  When  updates  were  needed  to  a  given  set  of  slides,  only  the  overlays  had  to  be 


transmitted.  The  text  provided  with  the  slides  described  the  essential  features  of  the 
displayed  graphics  information.  [Ref.  8:p.  56] 


EMS  was  the  principal  mechanism  for  transmitting  messages  between  the 
modules  of  the  DCP.  EMS  handled  all  standard  text  messages  as  well  as  non-text  material 
such  as  graphics.  Outgoing  mail  was  prepared  at  the  SDS  by  the  operator.  Incoming  and 
outgoing  mail  was  handled  by  the  gateway.  All  mail  was  stored  in  "mailboxes"  on  the  hard 
disk  of  the  mass  storage  station.  The  mail  could  be  called  up  for  reading  by  addressees, 
sent  to  the  shared  output  station  for  printing,  or  both.  [Ref.  8:p.  51] 

2  .  Module  Level  Bounding 

A  SPADS  module  consisted  of  one  or  more  staff  duty  stations,  a  mass  storage 
station,  a  shared  output  station,  and  a  communications  gateway  station,  all  interconnected 
by  a  local  area  network.  Table  8  presents  a  summary  of  the  module-level  hardware  and 
communications  capabilities. 

The  mass  storage  station  (MSS)  was  the  primary  shared  memory  for  the  SPADS 
module.  It  normally  contained  all  of  the  data,  text,  graphics,  and  computer  programs  for 
each  module.  The  MSS  consisted  of  a  hard  disk  drive,  a  hard  disk  server,  and  a 
videocassette  recorder  (VCR).  The  server  controlled  access  to  the  hard  disk  and  its 
operations.  These  included  local  work  files  used  by  each  SDS  as  well  as  common  data 
base  files.  The  VCR  was  used  to  create  a  backup  copy  of  the  hard  disk.  Only  one  MSS 
was  installed  at  each  module. 

The  shared  output  station  (SOS)  provided  medium-speed,  medium-volume 
printing  and  plotting  capability  to  support  the  module's  SDS  operators.  An  SOS  consisted 
of  an  SDS,  a  printer,and  an  optional  plotter.  Some  modules  had  a  plotter  capable  of 
producing  large  map  overlays,  hard  copy  slides,  and  conventional  hard  copy  paper  plots. 
All  the  SDSs  in  a  module  had  access  to  the  SOS  for  their  printing  and  plotting  needs.  The 


SOS  was  essential  for  module  operations  during  OC1  because  the  SDSs  did  not  have  local 
printers  available.  [Ref.  8:p.  44] 


TABLE  8 

MODULE-LEVEL  HARDWARE  AND 
COMMUNICATIONS  CAPABILITIES 


Gateway  Microcomputer: 

•  Apple  11+  (four  required/gateway) 

-  Synertek  MOS  6502 

-  48K  (.  Expanded  to  128K) 

-  5  X  7  Dot  matrix  for 
280  x  192  array 

-  120V/50-60  Hz  power 
Corvusa  20  Megabyte  Hard  Disk: 

•  Winchester  technology 

•  64  device  capable  common  bus 

•  1000  foot  trunk  length 

•  Non-collision  network 


Communication  Hardware: 

•  Multichannel — TRC  151/145 

-  Bulk  encryption — KG-27 

-  300—1200  baud 

•  TASS  switching — TTC  38/41 

•  PTT-KG-84:  300— 1200  baud 
Software  Capabilities: 

•  Variable  packet  size 

•  RS  232/RS  422  protocols 

•  Error  detection  code 

•  Corvus  Constellation  protocol 


The  communications  gateway  station  (CGS)  was  the  link  between  each  SPADS 
module  and  all  the  other  cells  in  the  DCP.  It  was  mandatory  for  module  operation.  The 
CGS  consisted  of  three  Apple  11+  microcomputers,  up  to  four  modems,  and  two  B&G 
monitors.  Its  purpose  was  to  process  incoming  information,  control  the  transmission  of 


a  Corvus  is  a  registered  trademark  of  Corvus  Computers,  San  Jose,  California. 


The  DCP  consisted  of  a  network  of  SPADS  modules  with  one  gateway  per  corps 
command  post  module.  In  the  initial  distributed  command  and  control  network,  the  CGSs 
were  connected  via  the  Army  Tactical  Area  Switching  System  over  tactical  multichannel 


radios  or  cable  systems.  [Ref.  8:pp.  2S-30] 

C.  C2  SYSTEM  ARCHITECTURE 
1 .  Workstation  Level  Integration 

Once  V  Corps  had  working  staff  duty  stations  in  its  modules,  the  staff  began  to 
implement  manual  functions  either  through  provided  SPADS  software  or  through  local 
program  execution.  Chapter  II  presented  an  overview  of  the  functions  of  the  corps 
commander  and  staff  in  any  CP  configuration.  (Appendix  E  provides  an  in-depth  look  at 
the  tasks  that  must  be  performed  by  the  corps  staff.)  Even  before  SPADS  was  being 
formalized  in  procedures  and  SOPs,  resourceful  staff  personnel  were  using  SPADS  to  per¬ 
form  more  effectively. 

The  next  four  figures  present  the  integration  of  each  software  package  with  the 
C2  system  and  the  C2  process.  First,  Figure  3.3  displays  the  integration  of  system, 
process,  and  function  with  Current  Situation  [Ref.  8:pp.  48-49],  then  Figure  3.4  shows 
the  integration  of  entities,  structure,  and  functions  with  Briefing  [Ref.  8:pp.  56-57].  Next, 
Figure  3.5  illustrates  the  integration  of  Electronic  Mail  System  with  the  processes, 
structures  and  entities  [Ref.  8:pp.  51-52].  Finally,  Figure  3.6  depicts  the  integration  of 
system  elements  and  functions  with  Local  Program  Execution  [Ref.  8:pp.  44,  48,  62], 
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Figure  3.6.  Integration  of  Local  Program  Execution 


Throughout  OC1  the  addition  of  SPADS  hardware  and  software  was  slowly 
influencing  the  structure,  organization,  procedures,  and  information  flow  patterns  of  the  V 
Corps  command  posts.  In  comparison  to  Chapter  II’s  pre-DCP  architecture.  Figure  3.7 


presents  module-level  integration  within  a  generic  module  during  OC1. 

3  .  Network  Level  Architecture 

The  most  significant  integration  at  the  network  level  in  OC1  occurred  during  the 
period  that  covered  Crested  Eagle  82  and  Caravan  Guard  III.  In  March,  during  Exercise 
Crested  Eagle  82,  two  corps  modules  were  physically  dispersed  and  transmitted  files 
between  them.  Furthermore,  during  Exercise  Caravan  Guard  III  in  June  1982,  nine 
modules  of  the  V  Corps  DCP  concept  were  used  and  SPADS  links  were  established 
between  four  dispersed  modules.  In  addition,  the  8ID  main  CP  was  connected  to  the  V 
Corps  main  CP  through  SPADS  at  a  distance  of  almost  40  kilometers. 

Once  the  corps  was  able  to  support  the  DCP  concept  through  SPADS 
communications  gateway  stations,  it  was  in  a  position  to  begin  integration  of  the  V  Corps 
C2  process  from  the  individual  staff  duty  stations  throughout  the  entire  network. 

D.  DATA  GENERATION 

The  data  generated  for  this  OC  are  shown  in  Table  95  .  The  data  generation  worksheet 
and  formulas  discussed  in  Chapter  II  were  used  to  produce  values  for  this  OC.  The  means 
for  each  evaluation  category  are  displayed  in  Figure  3.8.  A  brief  review  of  the  data 
generation  procedures — presented  in  Chapter  II — follows  in  the  next  paragraph. 


5  The  following  sources  provided  raw  data  on  these  exercises:  Reference 
(REFORGER  81,  Able  Archer  81,  Crested  Eagle  82,  Caravan  Guard  III),  Reference  10 
(Caravan  Guard  III),  Reference  1 1  (Caravan  Guard  III),  and  Reference  12  (Caravan  Guard 
III). 


Figure  3.7.  Integration  at  the  Module  Level  in  Operational  Capability  1 


C2/FE 


After  action  and  lessons  learned  reports  were  collected  from  V  Corps,  DNA,  and  the 
developer  for  each  exercise  during  this  operational  capability  cycle.  Using  the  worksheet, 
definitions,  and  procedures  specified  in  Chapter  II,  values  were  determined  for  each 
measure  from  every  exercise.  The  measures  were  individually  considered  as  binary 
conditions  for  each  DCP  module  that  participated  in  the  exercise.  The  summed  measures 
(e.g.,  FAIR,  XMOTi,  and  XCSTi)  received  their  cumulative,  unweighted  scores  based 
upon  their  constituent  measures  of  performance  or  effectiveness.  The  final  measure, 
C2/FE,  was  computed  as  a  linear  function  of  XMOTi  and  XCSTi  and  recorded  on  the 
worksheet.  The  results  for  each  exercise  are  displayed  in  Table  9,  and  the  means  for  each 
category  are  presented  in  Figure  3.8. 

The  reader  should  exercise  caution  in  interpreting  the  values  generated  for  OC1.  The 
scarcity  of  data  and  the  biases  noted  in  Chapter  n  lead  to  a  necessarily  conservative  view  of 
the  accomplishments  of  the  V  Corps  DCP  program  during  this  17-month  period. 

E.  AGGREGATION  AND  INTERPRETATION  OF  MEASURES 


1.  C2  Mission  Orientation 

The  value  of  C2  mission  orientation,  XMOTi,  rises  dramatically  during  OC1. 
This  may  be  a  gain  in  effectiveness;  however,  it  may  also  represent  the  natural  reaction  to 
coping  with  the  dispersed  command  post  environment.  The  following  subsections  interpret 
the  three  components  of  C2  Mission  Orientation, 
a.  C2  Process 

There  was  a  dramatic  loss  in  functionality  during  OC1,  and  SPADS  could 
have  been  exploited  to  regain  the  level  of  functionality  that  existed  before  dispersal[Ref.  12: 
pp  21-22j.  While  the  functions  of  the  V  Corps  commander  and  staff  remained  constant, 
the  environment  they  had  to  work  in  changed  drastically.  The  rise  in  FAIR  represents  the 
increasing  functionality  of  the  SPADS  system  within  the  DCP  environment. 


b.  Physical  Entities 


The  physical  entities  of  the  V  Corps  C2  system  changed  the  most  during 
this  period.  As  the  facilities  were  dispersed,  new  hardware  and  software  was  introduced  to 
increase  command  survivability  and  bring  C2  mission  orientation  up  to  its  pre-dispersal 
level.  The  value  of  capacity  remained  constant  for  each  module  that  was  added  to  the  DCP, 
but  the  total  aggregated  value  increased  as  the  modules  were  networked  by  the  gateway  and 
through  TASS  to  one  another. 

c .  Structural  Components 

The  valui  of  the  structural  measure  remained  at  zero  throughout  OC1. 
SPADS  was  not  able  to  accomplish  the  transmission  of  critical  information  required  by  the 
commander  during  this  period.  During  each  exercise  more  traffic  was  generated  than  in 
previous  ones,  but  at  no  time  could  the  V  Corps  commander  depend  on  SPADS  for  critical 
decision  making  information. 

2.  Command  Survivability 

SPADS  was  able  to  make  significant  gains  towards  achieving  command 
survivability  during  OC1.  Dispersion  between  modules  gradually  increased  from  zero  up 
to  48  kilometers — well  beyond  the  minimum  ten  kilometers  required.  On  the  other  hand, 
no  progress  at  all  was  made  toward  redundancy;  this  specifically  related  to  command 
influence  and  staff  interest.  Previous  Army  C2  systems  and  research  studies  indicated  that 
if  the  commander  did  not  provide  personal  leadership  and  demand  use  of  the  system,  then 
the  staff  members  would  only  use  it  in  a  haphazard  manner.  [Ref.  13:pp.  2-8  -  2-1 1,  2-39 
-  2-42]  Finally,  the  values  of  reliability  remain  constant  throughout  OC1,  while  the  value 
for  transportability  rises  to  a  steady  level  by  Exercise  Caravan  Guard  III. 
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3  .  C2  Force  Effectiveness 

SPADS  clearly  evolved  during  0C1  based  upon  the  operational  lessons  learned. 
However,  it  is  not  clear  that  it  evolved  as  a  C2  force  effectiveness  system  during  this 
17-month  period.  The  evolution  involved  hardware,  software,  protocols,  and 
communications  interfaces.  SPADS  had  not  affected  the  organization,  procedures,  or 
concept  of  operations  for  the  V  Corps  command  posts.  The  dramatic  rise  in  the  value  of 
C2/FE  is  directly  related  to  the  increase  of  XMOTi  during  the  period;  more  specifically,  it  is 
related  to  the  values  of  FAIR  which  measure  the  interactions  of  the  C2  process.  The 
measure  of  the  structural  component  remains  zero  throughout  OC1;  therefore,  it  must  be 
stated  that  C2/FE  does  not  "evolve"  during  this  period. 

Figure  3.9  provides  the  cumulative  (unweighted)  value  of  each  evaluation 
category  for  each  exercise  of  OC1.  Figure  3.10  displays  the  increasing  value  of  each 
measure — XMOTi,  XCSTi,  C2/FE — throughout  each  exercise  of  the  first  operational 
capability. 

F.  SUMMARY 

A  basic  workstation  concept  was  demonstrated  in  Exercise  REFORGER  81  during  the 
month  following  contract  award.  By  Exercise  Crested  Eagle  82,  the  SPADS  concept  was 
being  verified  with  two  modules  passing  data  over  encrypted  TASS  circuits.  The 
experiment  was  accelerated  with  the  deployment  of  nine  modules  in  Exercise  Caravan 
Guard  III  in  June  1982.  The  V  Corps  rear,  RAOC,  and  TAC  CP  modules  were  dispersed 
some  19  to  45  kilometers  from  the  main  CP  and  a  connection  was  made  to  the  8ID  main  CP 
SPADS  system  at  a  distance  of  48  kilometers.  The  main  CP  itself  was  broken  up  into  five 
modules  with  dispersion  simulated  by  distances  of  100  to  400  meters  between  modules. 
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Figure  3.9.  Evaluations  of  the  Three  Problems  for  OC1 


Comparisons  of  the  Three  Measures  for  OC1 


The  rapid  deployment  ot  equipment,  the  limited  training  time  allocated  to  the  staff  and 
operators,  and  the  lack  of  command  influence  and  staff  interest  resulted  in  a  mediocre 
demonstration  of  the  SPADS  system's  ability  to  effectively  support  a  dispersed  command 
post.  Nor  was  SPADS  able  to  obviously  enhance  the  commander’s  ability  to  achieve 
mission  objectives  during  this  period.  However,  the  DCP  concept  had  shown  that  it  could 
be  technically  viable  if  SPADS  equipment,  software,  procedures,  and  interface  could  be 
improved  during  the  next  OC.  The  key  to  success  for  SPADS  would  have  been  the  direct 
influence  of  the  commander,  and  the  role  the  staff  took  in  integrating  SPADS  into  the  entire 
V  Corps  C2  system  [Ref.  13:pp.  2-39  -  2-42]. 
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IV.  OPERATIONAL  CAPABILITY  2 

A.  PROBLEM  DEFINITION 

The  second  operational  capability  (0C2)  began  field  testing  in  September  during 
REFORGER  82.  OC2  was  planned  and  designed  to  use  OC1  as  a  baseline  condition  and 
progress  from  there.  Once  again,  designs  and  capabilities  were  tested  and  refined  during 
the  operational  capability's  four  exercises:  REFORGER  82,  Able  Archer  82,  Wintex  83, 
and  Caravan  Guard  IV. 

This  section  addresses  four  issues  central  to  problem  formulation: 

1 .  What  were  the  stated  requirements  of  OC2? 

2.  What  tasks  from  the  statement  of  work  (SOW)  supported  OC2? 

3 .  What  other  design  principles,  mandated  by  DNA,  guided  the  development? 

4.  What  were  the  goals  of  each  exercise? 

Figure  4. 1  shows  the  seven  requirements  of  OC2  along  a  month  by  month  timeline. 
The  dates  of  the  four  exercises  during  OC2  are  marked  by  and  are  listed  below  the 
central  rectangle.  The  objectives  of  OC2,  based  upon  requirements  and  technological 
characteristics,  are  shown  to  the  right. 

1  •  Requirements  for  OC2 

The  seven  OC2  objectives  to  be  completed  during  the  19-month  period  were:  (1) 
development  of  videodisc-generated  maps  and  overlays,  (2)  distributed  and  replicated  data 
bases,  (3)  minimized  data  transmission  with  automated  reporting  capabilities,  (4) 
development  of  a  16-bit  microprocessor  communications  gateway  station,  (5)  dispersal  and 
effective  operation  of  13  modules  in  the  V  Corps  DCP  concept,  (6)  full  implementation  of 
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Figure  4.1.  Overview  of  Operational  Capability  2 


the  SID  DCP  concept,  and  (7)  fielding  of  an  improved  Apple  communications  gateway 
station. 

a.  Videodisc-generated  Maps  and  Overlays 

OC2  specified  videodisc- generated  map  and  overlay  capabilities  that  used 
standard  map  images  and  overlays  of  military  symbols  or  icons.  The  maps  were  to  be 
stored  on  videodisc.  To  minimize  data  transmission,  only  overlay  images  were  to  be  sent 
electronically.  [Ref.  8:pp.  32-33 J 

b.  Distributed  and  Replicated  Data  Bases 

The  DBMS  was  to  provide  the  basic  capability  for  an  operator  to  extract 
information  from  the  data  base  and  to  enter  new  or  update  information.  The  SPADS 
DBMS  was  to  provide  the  staff  with  a  flexible,  responsive  and  powerful  data  base.  Two 
data  bases  were  scheduled  to  be  delivered  at  the  beginning  of  OC2:  the  Battlefield 
Information  Reporting  System  (BIRS),  and  the  Order  of  Battle  (OB).  The  BIRS  data  base 
was  to  be  constructed  to  store  friendly  force  data;  the  OB  data  base  would  provide  storage 
for  enemy  force  information.  These  were  to  be  replicated  data  bases  that  would  be  updated 
throughout  the  SPADS  network,  and  all  SDSs  would  be  able  to  obtain  the  same  current 
information  from  their  local  module's  hard  disk.  [Ref.  8:pp.  32-33] 

c.  Minimized  Data  Transmission  with  Automated  Reporting 

Capabilities 

Automated  reporting  capabilities  were  to  be  designed  so  that  only  data  (and 
not  the  report  format)  would  be  transmitted  electronically.  This  requirement  was  similar  to 
the  capability  achieved  in  OC1  where  only  graphics  overlays  were  transmitted.  [Ref.  8:p. 


d.  16-bit  Microprocessor  Communications  Gateway  Station 

Development 

This  requirement  marked  a  technological  enhancement  in  the  gateway 
function.  The  CGSs  were  taxed  to  their  limits  during  full-up  tests  of  the  DCP.  Therefore, 
a  newer  generation  microcomputer  with  16-  and  32-bit  architecture  was  to  be  selected  to 
increase  the  speed  of  message  traffic  transmission  and  reception.  [Ref.  8*p  33] 

e .  Dispersal  and  Effective  Operation  of  13  Modules  in  the 

V  Corps  DCP  Concept 

The  DCP  experimentation  program  was  to  continue  until  the  entire  V  Corps 
command  post  structure  could  be  fully  dispersed  while  effectively  performing  all  corps 
battle  tasks.  This  phase  of  the  program  was  to  progress  from  the  accomplishments  of 
OC1.  Full  dispersal  would  be  conducted  in  parallel  with  the  refinement  of  SPADS  system 
requirements  and  the  technological  enhancements  necessary  to  meet  all  of  the  OC's 
objectives. 

After  action  or  lessons  learned  reports  would  be  prepared  for  each  exercise 
conducted  during  the  time  period  of  this  operational  capability  (June  1982  through 
December  1983).  [Ref.  8:pp.  28-31] 

f.  Full  Implementation  of  8ID  DCP  Concept 

During  OC1  the  8ID  made  progress  toward  employing  a  DCP  concept. 
During  OC2  further  resources  were  to  be  dedicated  to  developing  a  more  rugged, 
transportable  and  survivable  version  of  the  SPADS  dispersed  command  post  environment. 
[Ref.  8:p.  33] 

g.  Improved  Apple  Communications  Gateway  Station 

Selecting  a  more  powerful  CGS  (Requirement  d.)  was  a  long-term  solution 
to  the  gateway  problem.  A  short-term  fix  was  required  to  support  the  8ID  DCP  concept 
and  to  provide  a  smaller,  more  capable  CGS  for  all  modules.  [Ref.  8:p.  33] 


a.  Task  7:  Support  for  REFORGER  and  Able  Archer 

This  task  provided  for  "on-site"  contractor  support  at  V  Corps  for  120  days. 
It  would  support  a  limited  SPADS  demonstration  during  REFORGER  82  and  fund  a  test  of 
the  full-up  DCP  concept  during  Able  Archer  82.  It  was  to  provide  assistance  to  V  Corps  to 
develop  SOPs  for  each  functional  area  of  the  staff.  Finally,  it  would  provide  for 
corrections  and  refinements  to  the  software  developed  under  Task  3  in  OC1. 

b.  Task  8:  8ID  AirLand  Battle  CP  Program 

Sub-task  8e  would  continue  8LD  support  through  REFORGER  82. 

c.  Task  9:  Baseline  Support 

This  task  provided  for  support  during  REFORGER  82,  Able  Archer  82, 
Wintex  83,  and  Caravan  Guard  IV.  This  support  was  to  increase  the  overall  effectiveness 
of  the  system,  increase  user  friendliness  and  improve  clarity. 

d.  Task  10:  On-site  Support  through  Wintex  83 

This  task  required  that  the  developer  coordinate  with  the  V  Corps  staff  to 
clarify  staff  requirements  for  SPADS  development. 

e.  Task  11:  16-bit  Microprocessor  Communications  Gateway 

Station 

Task  11  began  the  gateway  software  conversion  from  the  Apple  II  8-bit 
code  to  the  Corvus  Concept  16-  and  32-bit  code. 

f.  Task  12:  SPADS  System  Training  Documentation 

Task  12  required  that  written  and  audiovisual  instructional  materials  be 
developed.  The  written  materials  would  include:  (1)  a  User's  Guide  to  the  software 
capabilities,  (2)  a  Technical  User's  Guide  to  assist  system  managers  in  operating  the 
gateways  and  gaining  a  deeper  understanding  of  module  operations,  and  (3)  a  Concept  of 
Operations  Manual  aimed  at  educating  staff  officers  about  SPADS. 


g.  Task  13:  DCP  Videodisc  Support 


This  task  was  not  specified. 

h.  Task  14:  Support  to  Exercise  Caravan  Guard  IV 

The  final  task  for  OC2  provided  for  support  for  pre-exercise  training, 
equipment  upgrades,  and  exercise  support  for  Caravan  Guard  IV.  The  equipment  upgrades 
would  include  the  new  ACTO  mini-SDS  for  the  CBC  and  Intel  modules  as  well  as  an 
upgrade  for  the  Apple  CGS.  The  Army  Training  Support  Center,  Fort  Eustis,  VA, 
provided  $770,000  in  March  1982  to  purchase  microcomputers,  videodisc  players,  hard 
disk  drives  and  computer  networking  equipment  to  support  Caravan  Guard  IV.  This  was  a 
joint  effort  of  V  Corps,  ACTO,  DNA,  FORSCOM  and  TRADOC's  Combined  Arms 
Training  Development  Activity.1 

3  .  DNA  Design  Principles 

The  second  operational  capability  continued  to  follow  the  original  five  DNA 
design  principles  specified  in  OC1.  It  also  added  two  more.  These  principles  would  be 
continued  throughout  OC2.  [Ref.  8:p.  16] 

a.  Automate  Map  Graphics 

The  objective  of  this  design  principle  was  to  minimize  the  "culture  shock" 
problem  associated  with  new  technology.  Videodisc  technology  was  to  be  used  to  store 
thousands  of  color  photographs  of  standard  military  maps.  The  map  images  were  to  be 
overlayed  with  standard  military  symbols  and  displayed  on  a  color  monitor.  This  method 
would  avoid  the  use  of  computer- generated  maps  which  seemed  less  realistic  and  required 
extensive  retraining  (in  the  early  1980s).  This  technique  had  several  secondary  benefits: 


1  Interview  between  R.  Laird,  Lieutenant  Colonel,  USA,  Defense  Nuclear  Agency 
Alexandria,  Virginia  and  the  author,  17-18  December  1987. 


1 .  Everyone  would  use  the  same  maps 

2 .  Various  combinations  of  friendly  and  enemy  units  could  be  displayed 

3 .  The  problem  of  working  on  map  comers  would  be  minimized 

All  these  C2  functions  were  carried  out  manually  at  the  start  of  OC2.  DNA 
believed  that  it  would  be  impossible  to  operate  efficiently  in  a  DCP  environment  without 
automated  map  functions.  [Ref.  8:pp.  19-20] 

b.  Develop  a  User-friendly  System 

Using  familiar  formats  and  simply  operated  equipment  would  ensure 
effective  operation  under  high  levels  of  stress.  This  design  principle  involved  the 
application  of  the  following  concepts: 

1 .  Programs  would  provide  prompts  to  the  operator  on  which  steps  to  take  to  perform 
each  function 


2.  The  automated  map  display  would  use  images  of  standard  army  maps  (stored  on 
videodiscs)  that  presented  an  identical  appearance  to  other  maps  in  the  command  post 

3 .  The  graphics  backgrounds  and  message  formats  would  be  designed  to  look  like  the 
paper  copies  of  messages  already  in  use 

Users  would  not  have  to  learn  any  new  formats,  and  standard  Army  formats 

would  be  used  as  extensively  as  possible.  [Ref.  8:p.  21] 


The  overall  objective  of  Exercise  REFORGER  82  was  to  conduct  a  limited  test  of 
the  SPADS  system  that  emphasized  testing  communications  and  components.  The  sub¬ 
objectives  were  to  [Ref.  14:p.  1]: 

1 .  Establish  successful  data  transfer  between  V  Corps  and  two  8ID  elements 

2.  Experiment  with  the  use  of  three  different  types  of  modems  to  determine  which 
could  best  support  SPADS 

3.  Test  the  uninterruptable  power  supply  (UPS)  using  field  generator  power  at  8ID  and 
German  commercial  power  at  V  Corps  main  CP 


4.  Conduct  on-site  training  of  V  Corps  and  8ID  personnel 


5 .  Demonstrate  the  videodisc  system  of  SPADS 


The  overall  objective  of  the  next  exercise,  Able  Archer  82,  was  to  conduct  a 
limited  test  of  the  SPADS  system  that  emphasized  two  aspects:  the  testing  of  power,  and 
the  feasibility  of  a  distributed  data  base  system.  The  sub-objectives  for  the  exercise  were 
[Ref.  15:p.  1]: 

1 .  Test  the  isolation  transformers  and  the  UPS  in  a  field  environment 

2.  Continue  training  V  Corps  personnel  on  SPADS 

3 .  Demonstrate  videodisc  and  plotter  capabilities 

The  major  objective  during  Wintex  83  was  to  test  the  capability  of  the  SPADS 
prototype  to  provide  information  exchange  and  display  capabilities  in  support  of  the  DCP 
concept.  The  sub-objectives  included  field-testing  of  the  recently  deployed  videodisc 
equipment  and  the  new  database  management  system  (DBMS).  [Ref.  16:p.  1-1] 

V  Corps  deliberately  limited  the  SPADS  test  objectives  during  Exercise  Caravan 
Guard  IV  in  order  to  concentrate  on  the  following  sub-objectives  that  were  deemed  critical 
to  the  success  of  the  V  Corps  DCP  experiment  [Ref.  17:p.  II- 1]: 

1 .  Establish  and  maintain  a  SPADS  link  with  8 ID 

2.  Successfully  transmit  time-sensitive  tactical  information  within  V  Corps  and  between 
V  Corps  and  8ED  using  EMS 

3 .  Integrate  the  new  ACTO  mini-SDSs  into  CBC  operations 

4.  Experiment  with  methods  of  updating  the  SPADS  data  base 

The  8ID  also  limited  the  objectives  for  this  exercise  to: 

1 .  Demonstrate  SPADS  reliability  by  keeping  all  modules  operational  throughout  the 
exercise 

2.  Successfully  transmit  EMS  messages  among  8ID  modules  and  with  V  Corps 

3 .  Maintain  the  current  battle  data  through  Current  Situation 

Table  10  presents  an  overview  of  the  exercises  and  objectives  for  OC2  [Ref. 
8:pp.  28  -  30], 
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This  section  uses  the  same  approach  as  Chapter  III.  First,  the  workstation  bounds  of 
the  hardware  and  software  are  described.  Then,  the  module  level  describes  the  SPADS 
entities  and  structure  within  the  confines  of  one  modular  command  post.  Finally,  the 
network  level  defines  the  SPADS  system  within  the  procedural,  geographical,  and 
hierarchical  bounds  that  interconnect  the  modules. 


TABLE  10 

OVERVIEW  OF  OPERATIONAL  CAPABILITY  2 

Primary  Objective(s)  Date 

Sept.  1982 

•  Interface  V  Corps-8ID 
•Improve  communications  gateway 


Nov.  1982 

•Field  power  system  enhancements 
•Validate  distributed  data  base 
•Deploy  8ID  in  vans 


March  1983 

•Disperse  full  corps  command  post 
•Field  Automated  replicated  data  base 
•Field  video  battlefield  display  system 


Exercise  Caravan  Guard  IV  May  1983 

•Disperse  and  displace  8ID 

•Create  V  Corps-8  ID  command  data  base 


1 .  Workstation  Level  Bounding 
a.  Hardware 

The  only  new  hardware  introduced  at  the  workstation  level  during  OC2 
either  involved  enhancements  to  the  SDS  or  supported  a  completely  new  function.  The  five 
peripheral  devices  added  to  the  staff  duty  station  were  a  local  printer,  a  videodisc  player,  a 
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graphics  overlay  device,  a  joystick,  and  a  graphics  tablet.  The  local  printer  reduced  the 
competition  at  the  SOS.  The  videodisc  player  and  graphics  overlay  device  (both  required 
by  VBDS)  were  packaged  in  a  rugged  case  that  could  be  placed  underneath  the  standard 
SDS  to  support  the  new  automated  map  and  overlay  functions.  The  joystick  allowed  the 
SPADS  operator  to  scroll  and  zoom  tiie  picture  display,  offering  greater  control  the  view  of 
the  batdefield  within  VBDS.  The  graphics  tablet  was  useful  both  in  preparing  slides  and  in 
sketching  plans  or  evaluations  of  the  battlefield  situation  to  be  overlayed  on  the  map 
display.  [Ref.  17:pp.  36-40] 

The  videodisc  system  wa  st  demonstrated  to  V  Corps  and  8ID  during 
Exercise  REFORGER  82.  Both  headquarters  considered  it  an  important  capability  and 
expressed  their  desire  to  have  it  integrated  into  their  SPADS  modules  [Ref.  13:p.  9],  The 
videodisc  system  was  demonstrated  a  second  time  for  acceptance  testing  during  Exercise 
Able  Archer  82.  Again,  V  Corps  and  8  ID  were  impressed  by  the  C2  enhancements 
offered  by  these  capabilities  [Ref.  I5:p.  8|. 

During  the  SID  CPX  in  December  1982,  there  were  a  large  number  of 
hardware  failures  at  the  module,  workstation  and  lower  levels.  A  variety  of  the 
components  needed  to  be  repaired  during  this  exercise  (e.g.,  floppy  disk  drives,  Apple 
microcomputers, circuit  cards),  and  a  large  number  of  individual  integrated  circuit  chips  had 
to  be  replaced.  They  were  destroyed  by  power  surges,  grounding  problems,  and 
unbalanced  electrical  loads  on  the  SPADS  equipment  (Ref.  1 8 : pp .  8-14], 

An  obvious  factor  that  contributed  to  an  incomplete  test  of  the  DCP  during 
OC2  concerned  the  capabilities  of  the  4-hit  Apple  11  gateway  configurations.  There  were 
many  valid  and  invalid  perceptions  arising  from  use  of  these  8-bit  gateways.  The  inherent 
limitations  of  the  microprocessor,  as  well  as  the  manner  in  which  software  had  to  be 
written  for  that  system,  required  excessive  "chaining"  and  "swapping"  to  access  the  many 
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SPADS  programs  and  to  pass  tiles  :n:\  ,._n  the  communications  gateways.  These  two 
limitations  made  the  system  very  slo^.  particularly  when  under  heavy  use.  [Ref.  16:p.  II- 
10] 

During  Exercise  Caravan  Guard  IV  the  long-awaited  ACTO  SDS  was 
delivered.  This  configuration  would  soon  be  known  as  the  mini-SDS.  It  became  very 
popular  with  many  SPADS  operators  and  action  officers,  but  it  was  particularly  helpful  in 
the  cramped  CPs  at  the  division  level.  The  ACTO  SDS  consisted  only  of  an  Apple  11+ 
microcomputer,  two  5-1/4-inch  floppy  diskette  drives,  a  thermal  printer  and  a  single  B&G 
menhir  in  a  small  ruggedized  container.  |  Ref.  !7:p.  11-5] 
b.  Software 

Software  development  during  OC2  was  divided  between  adding  new 
functions  for  the  SPADS  user,  or  correcting  or  enhancing  functions  from  OC1.  The  new 
functions  were  the  Database  Management  System  (DBMS)  and  the  Video  Battlefield 
Display  System  (VBDS).  DBMS  allowed  the  staff  officer  or  user  to  maintain  and 
manipulate  data  [Ref.  8:pp.  56,  60 1.  VBDS  displayed  an  image  of  a  standard  military  map 
with  an  overlay  of  both  friendly  and  enemy  unit  locations,  status,  and  other  battlefield  data 
[Ref.  8:p.  49].  One  other  function  that  was  introduced  was  HPITS,  which  allowed  direct 
access  communicadons  between  two  staff  duty  stations  in  different  modules  [Ref.  14:p.  6]. 

The  two  functions  implemented  during  OC1,  Current  Situation  and 
Electronic  Mail  System  (EMS).  were  both  substantially  improved  during  OC2.  Current 
Situation  was  able  to  access  the  local  printer  added  to  the  SDSs,  and  the  software  was 
speeded  up  over  several  exercises  |  Ref.  17:p.  II-5|.  Briefing,  which  provided  the  ability  to 
create  and  present  briefings  to  the  Current  Situation  software,  was  also  improved  during 
this  cycle  [Ref.  17 :p.  1 1-6 1 .  The  EMS  code,  improved  during  almost  every  exercise, 
allowed  the  operator  to  send  or  receive  standard  text  messages,  data,  graphics  and 


computer  code  [Ref.  1 5 : pp.  8-9|.  Table  !  I  provides  an  overview  of  the  OC2  software  at 
the  workstation  level. 
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V  Corps  had  repeatedly  expressed  criticism  for  the  commercial  data  base 
products  delivered  as  stopgaps  during  OC1.  Some  of  the  G1/G4  functions  could  be 
handled  by  commercial  spreadsheet  products  in  Local  Program  Execution,  but  their  usage 
was  limited  to  worksheet-type  formats  and  processing  [Ref.  14:p.  9].  The  new  SPADS 
DBMS,  using  the  commercial  data  base  programming  language  PDBase,  was  fielded 
during  Exercise  Wintex  83.  The  DBMS  incorporated  both  BIRS  and  OB  formats  for 
controlled  input  by  tfr  C"  Operations  and  G2  Intelligence  respectively.  Tables  12  and  13 
display  the  BIRS  and  OB  input  fields  respectively.  All  other  users  could  only  read  and  get 
reports  from  the  data;  they  did  not  have  the  capability  to  make  changes  to  the  data  base. 
Table  14  shows  the  BIRS  and  OB  report  formats  available  to  all  users  during  OC2.  The 
new  VBDS  function  automatically  extracted  the  current  force  data  for  overlay  displays 
[Ref.  16:p.  III-5]. 

The  VBDS  software  displayed  unit  and  battlefield  data  as  a  graphics  overlay 
over  a  map  image  stored  on  a  videodisc.  VBDS  took  the  data  for  graphics  from  VBDS 
files  on  the  module's  hard  disk.  These  files  contained  information  on  unit  location  and 
status,  control  measures,  and  other  battlefield  characteristics  required  for  a  realistic 
automated  map  display.  VBDS  files  were  updated  locally  through  the  SDS  with  data 
received  through  the  gateway  from  other  modules.  The  graphics  overlay  was  keyed  to 
UTM2  coordinates,  and  graphics  were  ad  justed  to  reflect  changes  in  scale  or  location.  A 
graphics  tablet  was  introduced  for  VBDS  during  OC2  to  input  additional  overlay  data  such 
as  phase  lines  or  boundaries.  |  Ref.  S:p.  3  1 1 
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2  Universal  Transverse  Mercator  projection. 
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By  Exercise  Wintex  85.  the  VBDS  code  had  been  rewritten  to  use  a  new 
videodisc  platter  that  contained  expanded  map  coverage  and  photos.  The  new  software 
added  a  PHOTO  option  on  the  menu:  this  option  identified  all  locations  for  which  photos 
were  available  on  the  map  being  viewed.  Although  the  G3  did  not  have  a  need  for  this 
function,  several  other  staff  sections  immediately  requested  information  on  the  availability 
of  photo  images  and  their  applications.  [Ref.  16:pp.  III-7,  III-8] 

2  .  Module  Level  Boundini; 

The  only  change  at  the  module  level  during  OC2  was  the  introduction  of  a  down¬ 
sized  communications  gateway  station  (CGS)  fo;  use  in  divisional  command  posts.  This 
smaller  model  had  a  more  limited  capacity  to  support  communications  links,  but  was 


TABLE  11 

BOUNDING  OC2  SOFTWARE 
AT  THE  WORKSTATION  LEVEL 


Relational  Data  Base 

•  PDBase  (modified)1 

•  Enemy  and  friendly  force  structure 

Video  Battlefield  Display 

•  Laser  disks  hold  map  images 

•  Overlay  text  symbols 

•  Accesses  the  two  data  bases 

Electronic  Mail 

•  Commercial  package 

•  Templates  or  free  text 

•  Standard  communication  procedures 


Briefing  System 

•  User-defined 

Graphic  Editor 

•  Two  commercial  packages 

•  Rubber  band  drawing 

•  Supports  graphic  tablet/joystick 

.System  Tools 

•  Word  processing 

•  Execute  user  software  locally 

•  Network  manager 


3  PDBase  is  a  registered  trademark  of  IOTC,  Inc. 
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TABLE  12 

BATTLEFIELD  INFORMATION  REPORTING  SYSTEM 
(BIRS)  INPUT  FIELDS 


LUnit . 
2:Bde . 
5:Ech 


3:Div 


6:DDHHMM 


4 -.Type 
Z 


7:Opcon . 


8:Enemy-Action 
9:  Mission 


OPERATIONS  STATUS  10:Mech 
CofMass/FLOT  13: _ 


1 1  :Ami 


12:Cav 


14: 

15: 

16: 

17: 

18: 

19: 

BATTLE  RESOURCES 

Color  Rating 

20:  Tank/auth 

21:Tank/OH  _ 

_  22:Tank  _ 

23:  HAW/auth 

24: HAW/OH  _ 

_  25:HAW  _ 

26:  MAW/auth  2 

7:MAW/OH  _ 

_  28:MAW  _ 

29:Personnel 

30:Tank  ammo 

31:HAW  ammo 

32:MAW  ammo 

33:Diesel  fuel 

34:Commo 

35:Main-CP  _ 

36:TAC-CP 

37:CDR's  Overall 
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TABLE  13 


fe£ 


ORDER  OF  BATTLE  (OB)  INPUT  FIELDS 


1 :  Report- number _ 

2:Unit-ID _  3:  Army _  4:Div _  5:Rgt 


6:Type _  7:Size _  8:Locution _ 

9:Main-CP _  10:Forward-CP _  1 1:CE  % 

12:Activity  _ 

13:Cont'd  _ 

i4:Month _  15:DDHHMM _ 


supported  by  more  efficient  code  which  allowed  it  to  operate  25  percent  faster  than  the 
original  CGS.  [Ref.  8:pp.  31-33] 

3.  Network  Level  Bournfe 

The  only  advancements  at  the  network  level  during  OC2  involved 
implementation  of  the  system  at  wider  or  deeper  levels.  The  Wintex  83  Exercise  was 
extremely  successful  in  demonstrating  that  the  corps  headquarters  could  operate  effectively 


in  the  dispersed  mode  [Ref.  16:p.  11-5].  No  apparent  degradation  of  C2  functions  were 
experienced  as  a  result  of  dispersing  the  CP  modules  over  a  large  area  during  that  exercise; 
however,  the  true  potential  of  SPADS  capabilities  was  not  tested  due  to  insufficient 
integration  of  support  requirements  in  central  C2  functions  [Ref.  16:p.  II-6]. 

The  following  exercise.  Caravan  Guard  IV,  simulated  the  dispersion  requirement 
and  merely  used  SPADS  to  pass  all  data  from  one  module  to  another.  Three  corps  modules 
(CBC,  FSE  and  Plans)  were  co-located  in  a  civilian  gymnasium  complex  while  the  Intel 
module  was  located  nearby  in  command  post  vans.  In  contrast,  8ID  spread  its  command 
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posts  over  a  wide  area,  operating  out  of  vans  and  tracked  vehicles  across  the  German 
countryside.  The  division  main  CP  was  approximately  40  kilometers  from  the  corps  main 
CP;  DTAC  was  about  30  kilometers  forward  of  the  division  main;  meanwhile  the  division 
rear  CP  was  located  some  20  kilometers  to  the  rear  of  the  SID  main  CP.  [Ref.  17 :pp.  T2, 
1-4] 
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TABLE  14 

DATA  BASE  REPORTS  AVAILABLE  DURING  OC2 

BIRS  REPORTS 


Unit  Composition 
Equipment  Status 
Detailed  Equipment 
FLOTandTASKORG 

Locations 

Missions 

Activity  of  Enemy 
Print  All  Reports 


Provides  tlr  v.  nposition  of  each  unit  sorted  by  OPCON 

Provides  the  color  codes  for  current  status  of  equipment 

Prints  detailed  equipment  status  to  SOS  only 

Prints  the  Front  Line  of  Troops  report  and  Task 
Organization  information  to  the  SOS  only 

Provides  the  UTM  coordinates  of  friendly  locations 

Provides  the  friendly  unit  missions  sorted  by  OPCON 

Provides  a  description  of  enemy  activity  in  friendly 
sector 

Prints  a  copy  of  each  report  tc  the  local  printer  only 
OB  REPORTS 


Unit  Location  History  Provides  a  history  of  a  particular  unit  over  time. 

(Requester  must  know  the  unit's  name  in  advance) 

Listing  of  Reports  by  Time  Provides  a  listing  of  Intelligence  reports  sorted  by  date 

Combat  Activity  Provides  the  combat  activities  of  all  units  or  a  particular 

unit.  Report  is  sent  to  the  SOS  only 
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C.  C2  SYSTEM  ARCHITECTURE 


Inteurntion 


Throughout  OC2,  software  and  hardware  changes  produced  new  opportunities 
for  the  staff  sections  to  interact  with  SPADS.  Although  only  two  new  software  packages 
were  introduced,  they  generated  more  interest  from  the  operationally  oriented  staff  elements 
than  any  of  the  previous  developments. 

The  next  two  figures  present  the  integration  of  the  two  new  software  functions 
with  the  C2  system  and  the  C2  process.  Figure  4.2  displays  the  integration  of  system, 
process  and  function  with  the  Database  Management  System  [Ref.  8:pp.  58-60],  Figure 
4.3  shows  the  integration  of  entities,  structure  and  functions  with  the  Video  Battlefield 
Display  System  software  [Ref.  8:pp.  53-55 ]. 

2  .  Module  Level  Integration 

The  addition  of  SPADS  hardware  and  software  slowly  influenced  the  structure, 
organization,  procedures  and  information  flow  patterns  of  the  V  Corps  and  8ID  command 
posts.  In  OC2  it  gradually  became  clear  that  without  expressed  command  interest  in  this 
experiment,  only  certain  staff  sections  or  elements  would  voluntarily  take  up  SPADS  as  an 
effective  C2  toolset;  most  staff  sections  just  ignored  SPADS  during  the  exercises.  The 
G3 — the  proponent  of  operations,  plans  and  training — would  have  been  the  logical  driving 
force  behind  a  system  that  could  restore  effectiveness  to  the  dispersed  CP  configuration. 
That  was  not  the  case,  however.  Only  two  modules — Fire  Support  and  Plans — took  full 
advantage  of  SPADS. 


Integration  of  Data  Base  Management  System 
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Figure  4.3.  Integration  of  Video  Battlefield  Display  System 


a.  Fire  Support 


The  V  Corps  Artillery  leadership,  from  the  commander  and  the  Assistant 
FSCOORD  down  to  the  FSE  staff  and  NCOs.  demanded  that  SPADS  meet  their  needs  for 
targeting  and  fire  support  management.  Those  leaders  invested  in  SPADS  by  making 
valuable  personnel  available  for  training  and  then  assigning  them  to  primary  SPADS  duties 
during  all  exercises.  The  FSE  module  achieved  SPADS  self-sufficiency  before  any  other 
modules.  The  FSE  staff  developed  its  own  procedures  for  integrating  SPADS  operations 
into  primary  functions  before  any  exercises  and  tested  them  throughout  OC2.  At  FSE's 
initiative,  FSE  and  Intel  modules  established  ih-'r  own  network  and  procedures  for  using 
SPADS  to  improve  the  processing  and  passing  of  critical  targeting  data  for  the  deep  attack 
[Ref.  16:pp.  11-15  -11-16].  The  TCATA  evaluation  during  Exercise  Wintex  83  found  that 
the  FSE's  procedures  worked  extremely  well  [Ref.  16:pp.  11-22  - 11-25]. 
b.  Plans 

The  G3  Plans  and  Exercise  officer  selected  a  highly  talented  and  aggressive 
NCO  at  the  beginning  of  OCl,  sent  him  to  all  of  SPADS  training,  and  assigned  him  as  the 
module  system  manager.  The  G3  Plans  came  to  expect  the  system  to  speed  up  and  smooth 
all  of  the  internal  operations  of  the  module.  All  Plans  action  officers  soon  became  adept  at 
using  the  system  to  produce  and  transmit  OPLANS  during  exercises.  In  Exercise  Wintex 
83,  the  Plans  module  transmitted  ten  OPLANS  and  seven  changes;  this  represented  a  400 
percent  increase  over  previous  exercise  results.  The  Plans  module  had  the  highest  system 
usage  per  individual  during  Exercise  Wintex  83.  [Ref.  16:p.  11-17] 

3  .  Network  Level  Architecture 

There  are  two  perspectives  in  examining  the  network  level  architecture  during 
OC2:  connectivity  and  procedures.  Communications  were  finally  starting  to  support 
SPADS  by  the  end  of  OC2.  in  addition,  numerous  novel  connections  were  made  to  the 


gateways  daring  this  cycle.  On  the  other  hand,  integrating  the  expanding  network 
architecture  into  the  organization  and  procedures  of  the  corps  or  division  had  been  a 
complete  failure.  This  section  examines  these  two  aspects  of  the  network  level.  Once  the 
corps  was  able  to  support  the  DCP  concept  through  SPADS  communication  gateway 
stations,  it  was  in  a  position  to  begin  integrating  the  V  Corps  C2  process  from  individual 
staff  duty  stations  throughout  the  entire  network, 
a.  SPADS  Connectivity 

Individuals  continued  to  achieve  resourceful  solutions  to  communications 
problems  throughout  OC2.  During  REFORGER  82,  soldiers  from  the  £ID  decided  to 
connect  the  SID  TAC  CP  gateway  to  another  gateway  some  180  feet  away  using  WD-1 
field  wire.  This  experiment  worked  so  well  that  they  used  that  connection  for  the 
remainder  of  the  exercise.  [Ref.  14:p.  8] 

The  V  Corps  Commander  requested  that  the  V  Corps  main  CP  SPADS 
gateway  connect  to  a  VII  Corps  pre-production  model  AN/UYQ-30,  Tactical  Computer 
Terminal  (TCT).  One  staff  duty  station  was  hardwired  to  the  TCT  using  a  military  version 
of  an  RS-232  interface.  Not  only  were  the  two  systems  physically  linkable,  but  they  could 
transfer  files  between  them.  DNA  observed  this  pairing  as  a  possible  candidate  for  future 
interoperability  funding.  A  successful  project  along  these  lines  would  have  given  the  V 
Corps  automated  C2  system  a  means  to  communicate  with  the  VII  Corps  militarized, 
automated  C2  system.  [Ref.  14:p.  9J 

By  exercise  Caravan  Guard  IV,  V  Corps  had  learned  how  to  effectively  use 
the  corps  multichannel  system  to  support  the  SPADS  network.  The  Corps  C-E  section  had 
begun  to  understand  how  to  accommodate  SPADS  requirements,  and  the  After  Action 
Report  indicated  that  the  corps  could  make  further  progress  in  the  future.  [Ref.  17:p.  II- 
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b.  Procedures 


At  the  start  of  OC2  there  were  no  SOPs — at  any  echelon — for  the 
employment  of  SPADS.  By  Able  Archer  82,  V  Corps  had  begun  to  make  limited  progress 
towards  identifying  the  information  necessary  to  develop  a  SPADS  SOP.  There  was  no 
SID  document  related  to  the  preparation  or  deployment  of  SPADS  [Ref.  15:pp.  7,  10].  A 
new  set  of  SPADS  manuals  were  delivered  to  V  Corps  in  January  1983.  The  Operator  and 
System  Manager  Manuals  were  distributed  immediately,  and  SPADS  operators  took  these 
manuals  to  the  field  during  the  last  two  exercises.  The  Staff  Officers'  Manual,  however, 
was  not  even  read  by  those  officers  with  primary  SPADS  responsibilities.  Even  though 
guidelines  for  an  extensive  SPADS  SOP  were  contained  in  the  manual,  no  SOPs  were 
developed  by  any  staff  section  after  this  information  was  distributed.  By  Caravan  Guard 
IV  only  a  Current  Situation  SOP  had  been  developed  by  any  staff  section  within  V  Corps. 
[Ref.  17 :p.  HI- 12] 

Two  of  the  primary  lessons  V  Corps  learned  after  the  series  of  exercises  that 
culminated  in  Wintex  83  were  that:  (1)  evolutionary  development  must  be  based  upon  user 
identification  of  needs,  and  (2)  system  capabilities  must  be  designed  and/or  enhanced  in 
accordance  with  deliberate  plans  to  integrate  SPADS  into  the  V  Corps  C2  processes. 
Unfortunately,  throughout  OC1  and  2  there  had  been  no  systematic  approach  to  defining 
and  testing  user  applications  or  in  integrating  them  into  command  post  routines  [Ref. 
16:pp.  11-26,  11-27].  The  TCATA  evaluation  of  SPADS  during  Wintex  83  should  have 
forced  the  commander  and  the  staff  to  recognize  their  situation.  The  outbrief  was  honest 
and  to  the  point:  V  Corps  either  had  to  embrace  SPADS  and  internalize  it  within  the  corps 
C2  system,  or  it  had  to  abandon  it  entirely.  [Ref.  16:pp.  11-27, 11-28] 


c.  Inhibiting  Factors 

The  two  principal  factors  inhibiting  the  progress  of  SPADS  throughout  the 
first  two  OCs  were:  (1)  insufficient  primary  staff  emphasis,  and  (2)  insufficient  integration 
of  SPADS  into  the  V  Corps  C2  processes  [Ref.  16:pp.  II-8  -  II- 10]. 

V  Corps  had  not  placed  sufficient  emphasis  on  educating  primary  staff 
officers  on  the  value  a  distributed  data  base  had  in  meeting  their  needs.  The  DCP  concept 
represented  a  dramatic  change  in  traditional  C2  procedures.  These  applications  were  seen 
as  foreign  to  tactical  operations  by  many  senior  officers  [Ref.  12:pp.  21-22].  Many  senior 
officers  conceded  that  these  methods  might  have  value,  some  even  gave  them  verbal 
support.  But  almost  uniformly  throughout  the  V  Corps  CP,  their  subordinates  were 
isolated  from  the  staff  duty  stations  and  SPADS  products  during  exercises  [Ref.  16:p.  II- 
8]. 

Conceptually,  the  SPADS  distributed  and  replicated  data  base  could  have 
provided  the  V  Corps  commander  with  the  critical  common  perception  of  the  battle  and 
with  specific  information  required  for  timely  decision  making.  Unfortunately,  most  of  the 
primary  staff  had  not  devoted  any  time  to  learning  SPADS,  nor  had  they  directed  their 
overburdened  subordinates  to  use  or  learn  SPADS.  As  a  result,  most  staff  sections  could 
not  identify  information  flows  that  would  satisfy  their  own  C2  functions  by  the  end  of 
OC2.  [Ref.  16:pp.  II-8  -  II-9] 

d.  Contributing  Factors 

Exercise  Caravan  Guard  IV  demonstrated  to  V  Corps  and  8ID  commanders 
that  SPADS  could  have  been  a  reliable  tactical  C2  system  during  the  DCP  experiment  if 
they  had  devoted  resources  to  proper  planning  and  operational  procedures.  They 
considered  the  overwhelming  success  of  these  exercises  as  the  first  step  in  a  new  phase  of 
SPADS  development.  At  the  post  exercise  In-Progress  Review,  V  Corps  adopted  a  draft 
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SPADS  charter  (displayed  in  Table-15)  and  adopted  a  tentative  plan  for  a  new 
organizational  element  for  controlling  SPADS  within  V  Corps.  [Ref.  17:pp.  11-14  - 11-16] 

TABLE  15 

V  CORPS  SPADS  CHARTER 

•  Develop  a  DCP  program  plan  with  specific  exercise  objectives 

•  Identify  and  prioritize  information  needs  to  support  procedures  and  decision  making 

•  Define  how  SPADS  works  in  each  module 

•  Develop  a  SPADS  program  plan  with  specific  exercise  objectives,  training 
requirements  and  organizational  responsibilities 

•  Develop  SOPs  for  DCP  and  SPADS 

•  Conduct  mini-CPXs  in  garrison  prior  to  each  exercise 

D.  DATA  GENERATION 

The  data  generated  for  this  OC  are  shown  in  Table  16.3  The  data  generation 
worksheet  and  formulas  discussed  in  Chapter  II  were  used  to  produce  values  for  this  OC. 
The  means  for  each  evaluation  category  are  displayed  in  Figure  4.4.  The  next  paragraph 
briefly  discusses  the  data  generation  procedures  presented  in  Chapter  n. 


4  The  following  sources  provided  raw  data  on  OC2  exercises:  Ref.  13  (REFORGER 
82),  Ref.  14  (Able  Archer  82),  Ref.  15  (Wintex  83),  Ref.  16  (Caravan  Guard  IV),  Ref.  17 
(8ID  CPX). 
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To  begin  the  data  generation  tor  this  operational  capability,  after  action  and  lessons 
learned  reports  were  collected  for  each  exercise  from  V  Corps,  DNA,  and  the  developer. 
Using  the  worksheet,  definitions,  and  procedures  specified  in  Chapter  II,  values  were 
determined  for  every  measure  from  each  exercise.  The  measures  were  individually 
considered  as  binary  conditions  for  each  DCP  module  that  participated  in  the  exercise  being 
evaluated.  The  summed  measures  (e.g.,  FAIR,  XMOTi,  and  XCSTi)  received  their 
cumulative,  unweighted  scores  based  upon  their  constituent  measures  of  performance  or 
effectiveness.  The  final  measure,  C2/FE,  was  calculated  using  the  procedure  specified  in 
Chapter  II.  The  results  for  each  exercise  are  displayed  in  Table  16,  and  the  means  fu  each 
evaluation  category  are  shown  in  Figure  4.4. 

E.  AGGREGATION  AND  INTERPRETATION  OF  MEASURES 

The  extensive  information  available  in  these  After  Action  and  Lessons  Learned  Reports 
(Ref.  14  -  18)  contained  a  great  deal  of  data  and  were  extremely  helpful  in  understanding 
the  characteristics  of  the  experiments  during  the  exercises. 

1*  C2  Mission  Qrfontatiyn 

The  value  of  C2  Mission  Orientation,  XMOTi,  seems  to  start  at  approximately 
the  same  level  as  OC1,  drops  sharply  and  then  rises  dramatically  at  the  end  of  OC2.  There 
is  a  measurable  gain  in  effectiveness  by  the  end  of  the  experiment  period;  however,  there 
was  a  tremendous  loss  of  functionality  during  the  period  of  REFORGER  82  through  the 
8ID  CPX  in  December  1982.  The  following  three  sections  interpret  the  three  components 
of  C2  Mission  Orientation. 

a.  C2  Process 


There  was  a  dramatic  loss  in  functionality  from  the  end  of  OC1,  in  June 
1982,  through  the  8ID  CPX  that  December  1982.  While  the  functions  of  the  V  Corps 
commander  and  staff  may  have  remained  constant,  the  DCP  environment  and  SPADS,  in 


particular,  caused  a  severe  decrease  in  the  commander's  and  staff s  abilities  to  exercise 
command  and  control  of  the  corps.  Only  the  sharp  rise  in  FAIR  values  during  the  last  two 
exercises  represents  the  increasing  functionality  of  the  SPADS  system  within  the  DCP 


environment. 

b.  Physical  Entities 

Physical  entities  continued  to  change  during  OC2.  Some  new  software  was 
introduced,  established  software  functions  were  constantly  refined,  and  new  hardware  was 
integrated  into  the  DCP  environment.  The  value  of  capacity  does  not  remain  constant  for 
each  module  that  was  already  in  the  V  Corps  DCP.  As  the  modules  were  rearranged  from 
exercise  to  exercise,  the  system's  capacity  diminishes  until  the  exercises  in  spring  1983. 
Then,  the  total  aggregated  value  increases  as  the  modules  were  networked  by  the 
communications  gateway  stations  to  one  another  through  TASS. 

c.  Structural  Components 

The  value  of  the  structural  measure  rises  slightly,  decreases  again,  and 
finally  steadies  at  the  end  of  OC2.  For  the  first  time,  SPADS  was  able  to  accomplish  the 
transmission  of  critical  information  required  by  the  commander.  Despite  peak  transmission 
periods  and  temporary  communications  outages  during  each  exercise,  SPADS  was  finally 
able  to  provide  the  V  Corps  commander  with  dependable,  critical,  decision  making 
information. 

2 .  Command  Survivability 

SPADS  continued  to  make  significant  gains  towards  achieving  command 
survivability  during  OC2.  Except  for  the  initial  three  command  post  exercises,  dispersion 
between  modules  gradually  increased  and  more  modules  were  added  to  the  corps  system. 
Continuing  the  trend  from  OC1,  no  progress  was  made  toward  redundancy;  this  continued 
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SPADS  did  evolve  during  the  operational  capability  based  upon  the  operational 
lessons  learned.  It  was  still  not  clear  how  much  progress  SPADS  had  made  during  this 
19-month  period.  The  evolution  involved  hardware,  software,  protocols  and 
communications  interfaces.  SPADS  only  began  to  affect  the  organization,  procedures  or 
concept  of  operations  for  the  V  Corps  command  posts  at  the  end  of  OC2,  during  the 
Caravan  Guard  IV  In-Progress  Review  [Ref.  17:pp.  11-14  -  11-16].  The  values  of  C2/FE 
rise  distinctly  at  the  end  of  the  experiment  period  when  the  V  Corps  and  8ID  scaled 
objectives  down  to  realistic  levels  and  sought  to  gain  maximum  advantage  from  their 
automated  C2  system.  The  values  of  all  significant  measures,  i.e.  XMOTi,  XCSTi  and 
C2/FE,  nearly  double  in  value  by  the  end  of  OC2. 

Figure  4.5  provides  the  cumulative  (unweighted)  value  of  each  evaluation 
category  for  each  exercise  of  OC2.  Figure  4.6  displays  the  changing  value  of  each 
measure — XMOTi,  XCSTi,  C2/FE — throughout  each  exercise  of  the  second  operational 
capability. 


F.  SUMMARY 

The  second  operational  capability  was  a  turbulent  period  for  V  Corps,  8ID  and  DNA. 
All  of  these  organizations  had  specific  objectives  for  this  period,  and  all  of  their  objectives 
failed  to  some  degree.  This  section  frankly  discusses  procedures,  training, 
communications,  hardware  and  software  as  they  relate  to  the  performance  of  the  V  Corps 
and  HID  DCP  experiments. 


Evaluations  of  the  Three  Problems  for  OC2 
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The  lessons  learned  from  the  SPADS  evolutionary  development  cycle  must  focus  on 
procedures  and  training  because  these  two  structural  components  are  critical  to  the  success, 
or  lack  thereof,  of  a  prototype  C2  system.  To  a  large  extent  they  determine  the 
effectiveness  of  the  fielding  and  implementation.  System  designers  should  have  been  more 
careful  planners,  thoughtful  schedulers  and  more  cognizant  of  requirements,  committed  to 
successful  implementation,  and  engaged  in  a  systematic  training  program  if  they  wanted  to 
insure  SPADS  user  effectiveness.  This  does  not  imply  that  system  and  personnel 
problems,  diagnoses,  fixes  and  modifications  that  resulted  as  a  response  to  system 
problems  would  not  have  occurred.  These  situations  are  a  necessary  part  of  any  rapidly 
fielded  system.  The  lessons  learned  by  users  in  the  field  environment  are  the  basis  for 
system  improvement  and  enhancement  in  an  evolutionary  development  cycle.  The  scope 
and  speed  of  the  system's  advancement,  measured  objectively,  was  significantly  influenced 
by  staff  priorities  for  the  system,  SOP  construction  and  revision,  and  the  staffs  attitude 
toward  effective  training  and  retraining.  [Ref.  8:p.  65] 


Throughout  the  evolutionary  development  cycle,  there  was  evidence  that  a  highly 
reliable  tactical  command  and  control  could  only  be  implemented  if  adequate  planning  and 
operational  procedures  were  employed.  A  critical  factor  in  the  success  of  this  evolutionary 
development  program  was  the  careful  definition  of  minimum  essential  information  and  the 
data  distribution  architectures  by  the  headquarters  staffs.  This  essential  step  was  almost 
totally  lacking  throughout  rhe  first  two  operational  capability  cycles.  [Ref.  8:p.  65] 

Emphasis  should  have  been  placed  upon  soliciting  and  coordinating  staff 
requirements  of  the  corps  and  division  headquarters.  These  staffs  significantly  failed  to 
produce  a  working  SOP  that  reflected  the  flow,  storage  and  retrieval  of  messages,  data  ,or 
briefings  from  SPADS.  Without  this  document,  staff  requirements  could  not  be  translated 


into  data  to  support  the  distributed  C2  system.  Also  lacking  was  a  listing  of  the  operator 
and  staff  officer  responsibilities  for  information  processing  procedures.  The  SOP  should 
have  indicated  who,  what,  when,  where  and  how  each  test  of  the  DCP  program  related  to 
the  functions  that  were  being  supported  by  the  staffs.  Little  time  was  available  for  this 
critical  document,  and  there  is  no  evidence  that  any  was  expended  to  accomplish  this  task. 
Its  completion  during  OC2  would  have  greatly  enhanced  the  quality  of  implementation  and 
the  rapid  fielding  of  the  distributed  C2  system.  [Ref.  8:p.  69] 

2.  Training 

The  h  adquarters'  staffs  should  have  carefully  scrutinized  the  personnel  selected 
for  training.  They  did  not  ensure  that  potential  operators  and  system  managers  had 
sufficient  time  to  gain  experience  with  SPADS.  Experienced  SPADS  users  could  have 
clearly  identified  those  procedures  that  could  have  been  better  automated,  pinpointed 
obsolete  functions  or  equipment,  and  identified  the  manner  in  which  new  operational 
procedures  could  have  been  implemented.  The  corps  would  have  obtained  an  ongoing 
program  that  produced  quality  operators  and  system  managers  who  could  have  significantly 
contributed  to  fine  tuning  SPADS  to  meet  the  Army's  needs.  [Ref.  8:p.  67] 

Two  other  integral  training  program  components  were  lacking.  On-the-job 
training  and  pre-exercise  rehearsals  were  equally  necessary  for  users  to  understand  the 
enemy  threat,  the  constraints  of  the  exercise  scenarios,  and  the  functions  of  SPADS  in  the 
DCP  environment. 

Training  documentation  should  have  reflected  the  level  of  sophistication  of  the 
commercial  technology  and  should  have  been  incorporated  into  SPADS  itself.  Self-paced 
documentation  could  have  been  available  for  the  user  who  recently  joined  the  organization 
or  who  missed  the  formal  training  cycle.  On-line  tutorials  using  SPADS  videodisc 
technology  could  have  been  substituted  for  the  lengthy  manuals  to  assist  the  operator  in 
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learning  how  to  set  up  and  operate  the  staff  duty  stations.  A  criucal  oversight  was  the  lack 
of  a  small,  weatherproof,  pocket-sized  reference  manual  that  could  be  carried  by  the 
operator  or  permanently  affixed  to  the  SDS;  this  would  have  been  superior  to  the  bulky 
system  documentation  that  was  nearly  always  damaged  or  left  behind  by  staff  officers  and 
users.  [Ref.  8:p.  67] 

Finally,  data  file  development  for  future  exercises  should  have  been  initiated  as 
soon  as  possible  within  the  guidelines  of  the  requirements  document  and  completed  before 
the  anticipated  move  to  field  locations.  Selected  operator  refresher  training  could  have  been 
conducted  concurrently  vif  this  development.  Following  the  move  to  the  field, 
immediately  after  system  equipment  and  communications  were  installed  and  operational, 
testing  and  demonstration  of  the  system  should  have  begun.  These  tests  and 
demonstrations  should  have  included  mini-exercise,  requirements-driven  scenarios  to 
insure  a  comprehensive  shakedown  of  SPADS  prior  to  commencement  of  the  exercise. 
[Ref.  8:p.  69] 

3.  Communications 

Both  the  V  Corps  Signal  Brigade's  and  Communications-electronics  (C-E)  staff 
section's  lack  of  involvement  with  SPADS  during  the  first  two  OCs  severely  affected  its 
development.  Their  early  involvement  was  absolutely  necessary  for  an  initial  good  start  as 
well  as  to  planned  progress  during  the  following  evolutionary  development  cycle.  As 
military  technical  consultants  to  the  system,  they  possessed  the  ability  to  determine  whether 
the  system  could  actually  meet  the  operational  needs  of  the  V  Corps  DCP  concept.  These 
communications  experts  would  have  been  an  excellent  source  of  advice  in  the  planning  of 
exercises,  and  could  have  insured  that  operational  staff  sections  conformed  to  the  new 
automated  procedures.  [Ref.  8:pp.  74-75 1 


Instead,  serious  interoperability  problems  caused  major  time  delays  and 
adversely  affected  the  goals  and  purposes  of  numerous  exercises  and  tests.  The  C-E  staffs 
involvement  would  have  insured  that  essential  time  was  devoted  to  testing  the  system, 
observing  the  man-machine  interface,  obtaining  user  feedback,  evaluating  system  usability 
and  meeting  the  requirements  of  the  OC.  Moreover,  these  communications  experts  could 
have  predicted  avoidable  problems  that  seriously  frustrated  new  operators  and  system 
managers  who  were  often  uncomfortable  in  their  roles,  and  could  have  contributed  to  the 
success  of  many  DCP  exercises.  [Ref.  8:p.  74] 

Another  area  where  expen  help  was  needed  was  in  the  communications  method 
used  to  connect  local  modules  to  one  another  and  to  other  modules  at  longer  distances. 
Operational  users  failed  to  learn  a  basic  lesson:  before  deploying  to  the  field,  users  need  to 
devote  considerable  time  to  planning  and  pre-exercise  engineering  in  order  to  ensure  a 
sufficiently  good  system  interface  and  a  better  chance  of  success  for  communicating 
between  microcomputer  based  systems.  The  C-E  staff  was  already  planning  and 
engineering  tactical  multichannel  systems,  and  they  should  have  assimilated  SPADS  into 
their  area  of  responsibility.  [Ref.  8:p.  74] 

Regardless  of  the  technological  advances  or  the  sophistication  of  the  system 
enhancements,  SPADS  could  not  meet  its  stated  objectives  unless  the  communications 
problems — especially  with  the  interface — were  remedied.  Experienced  communications 
planners  were  needed  to  make  provisions  for  the  distribution  of  information  among 
echelons  vertically  as  well  as  horizontally  across  staff  support  functions.  The  V  Corps 
Signal  community's  lack  of  involvement  prevented  reliable  and  reasonable  communications 
capabilities  from  being  planned  for  and  employed  during  the  first  two  operational  capability 
cycles.  The  most  significant  problem  in  communications  was  not  with  the  communicators 
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(.who  ignored  SPADS),  but  with  the  lack  of  command  influence  which  should  have  insured 
that  professional  communicators  were  involved  in  SPADS  from  the  outset.  [Ref.  8:p.  75] 

4.  Hardware 

The  hardware  lessons  learned  during  OC2  interact  with  the  lessons  learned  in 
preceding  summaries.  The  relatively  minor  hardware  problems  which  developed  during 
the  first  two  OCs  indicated  that  the  evolutionary  development  cycle  is  a  good  means  to  fine 
tune  hardware  components  that  have  to  be  fielded  quickly.  The  successes  of  the  SPADS 
system  hardware  in  meeting  and  exceeding  user  requirements  resulted  from  an  early 
fieldin_  strategy  and  hands-on  use  that  supported  the  effectiveness  of  the  evolutionary 
development  concept.  [Ref.  8:p.  83] 

It  may  seem  obvious  that  hardware  had  to  be  integrated  with  software  into  a 
usable  system  that  automated  the  V  Corps  operational  procedures  to  benefit  the  DCP. 
However,  the  field  users,  DNA,  and  the  developer  had  to  develop  a  three-way  dialogue 
before  they  could  produce  and  field  a  C2  system  that  permitted  the  staff  to  operate  more 
efficiently  and  allowed  the  commander  to  control  his  forces  effectively.  The  hardware  had 
to  possess  the  capabilities  required  to  support  the  system  software.  Moreover,  the  software 
had  to  be  tailored  to  meet  limitations  of  the  hardware  that  were  first  identified  during  field 
tests  and  exercises.  Only  in  this  manner  could  the  users  distinguish  between  hardware  and 
software  problems  in  the  SPADS  system.  [Ref.  8:p.  82] 

Hardware  that  was  difficult  for  the  average  military  user  to  operate  and  maintain 
would  be  abandoned  as  inoperable  during  high  stress  periods — when  it  was  most  needed  to 
contribute  to  a  survivable  system.  The  proponent  of  the  system  and  the  developer  should 
have  actively  obtained  feedback  about  the  system  hardware.  Staff  officers,  who  depended 
upon  SPADS  information  processing  and  decision  support  capabilities,  could  have  been 
among  the  best  reviewers  of  hardware  failures  and  inadequacies.  Moreover,  senior  staff 
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officers  were  in  a  unique  position  to  judge  how  the  staff  adjusted  operational  procedures  to 
the  constraints  imposed  by  the  system  hardware.  Likewise,  the  advice  of  SPADS 
operators  would  have  been  valuable  because  they  were  closest  to  the  hardware  problems 
and  were  the  most  likely  to  make  worthwhile  judgments  regarding  its  usability.  [Ref.  8:pp. 
82-83] 

5 .  Software 

The  interaction  effects  among  the  other  system  components  (procedures, 
training,  communications,  hardware  and  user  inexperience)  adversely  affected  the 
capability  of  SPADS  software  to  adequately  perform  its  intended  functions.  Software 
development  should  have  taken  these  constraints  of  the  users'  environment  into 
consideration.  A  positive  example  of  such  an  adaptation  was  how  the  developer,  after 
gaining  an  understanding  of  military  communications  traffic  loads  on  TASS,  developed 
software  that  only  transmitted  the  data  that  were  absolutely  essential.  It  was  not  necessary 
to  transmit  entire  files.  Other  successful  examples  include  message  formats  being  stored  on 
every  module's  hard  disk  and  all  maps  being  stored  on  videodisc.  Once  again,  only  the 
new  data  required  to  fill  in  reports  or  to  show  unit  locations  on  map  overlays  had  to  be 
transmitted  and  received.  [Ref.  8:pp.  87-88] 

During  the  first  OC,  there  were  many  instances  where  usability,  storage,  update 
or  retrieval  interfered  with  SPADS  effectiveness.  Throughout  the  second  OC  the  developer 
made  a  concerted  effort  to  minimize  those  software  deficiencies  that  adversely  affected 
operations.  However,  the  initial  fielding  and  testing  of  software  was  absolutely  essential  in 
order  to  identify  those  shortcomings  that  could  be  diagnosed  and  corrected  before  the 
following  exercises  and  test.  [Ref.  8:p.  86] 

The  majority  of  the  software  problems  that  occurred  during  the  second 
operational  capability  related  to  the  following  tasks  [Ref.  8:p.  85]: 


1 .  Tailoring  software  to  meet  operational  user  requirements  or  automation  needs 

2 .  Increasing  software  speed  and  efficiency 

3.  Fine  tuning  system  software  to  make  it  more  usable  and  responsive  to  staff  officers' 
needs 

4.  Eliminating  system  software  bugs  that  impede  the  execution  of  system  utilities 

5.  Advancing  the  software's  technological  capabilities  to  perform  more  sophisticated 
staff  operations 

6.  Integrating  existing  and  new  software  with  hardware  enhancements  that  develop  as 
the  system  matures  or  the  staff  functions  change 

Although  much  of  the  responsibility  for  software  remained  with  the  developer, 
staff  officers  should  have  ascertained  which  operational  functions  and  procedures  required 
automation  early  in  OCl.  These  officers  should  have  developed  SOP  documentation  that 
clearly  addressed  those  considerations  so  that  hardware  meeting  those  software 
requirements  could  have  been  carefully  selected  and  developed.  And  they  should  have 
identified  appropriate  data  structures  to  support  the  software  development.  The  developer 
could  not  foresee  future  changes  of  the  system,  so  staff  officers  should  have  concisely 
specified  the  procedures  and  functions  that  would  benefit  most  from  software  development. 
[Ref.  8:p.  87] 

6.  Outlook 

This  chapter's  summary  catalogued  the  myriad  sources  of  problems  that  afflicted 
the  SPADS  experiment  throughout  OC2.  In  spite  of  these  observations,  it  was  clear  that 
DNA  saw  SPADS  as  continuing  to  make  significant  progress  towards  the  fully  dispersed 
command  post  concept  for  both  the  corps  and  the  division.  Capabilities  demonstrated  in 
the  exercises  during  1982  and  1983  verified  the  viability  of  the  DCP  concept  in  employing 
a  prototypical  dispersed  C2  system  linked  through  standard  tactical  communications.  By 
the  end  of  OC2,  many  necessary  improvements  to  fully  implement  the  DCP  concept  and 
fully  support  SPADS  had  been  identified.  Therefore,  DNA  decided  to  continue  the 


experiment  through  the  end  of  Fiscal  Year  1985  to  fully  demonstrate  the  concept  and  to 
identify  and  improve  the  methodology  by  which  it  could  be  fully  implemented. 


V.  OPERATIONAL  CAPABILITY  3 


A.  PROBLEM  DEFINITION 

Funding  for  the  third  operational  capability  started  in  July  1983  and  field-testing  began 
in  September  during  REFORGER  83.  OC3  was  planned  and  designed  to  start  with  the 
first  two  operational  capabilities  as  a  baseline  condition  and  progress  from  there.  Once 
again,  designs  and  capabilities  were  tested  and  refined  during  the  OC's  five  exercises: 
REFORGER  S3,  Able  Archer  83,  Crested  Eagle  84,  Caravan  Guard  V,  and  REFORGER 
84.  The  Army  conducted  an  external  evaluation  of  SPADS  during  Wintex  85:  this  one 
exercise  is  also  considered  part  of  the  evaluation. 

This  section  addresses  four  issues  central  to  problem  formulation: 

1 .  What  were  the  stated  requirements  of  OC3? 

2 .  What  tasks  from  the  statement  of  work  (SOW)  supported  OC3? 

3 .  What  other  design  principles,  mandated  by  DNA,  guided  the  development? 

4.  What  were  the  goals  of  each  exercise? 

Figure  5.1  shows  the  eight  requirements  of  OC3  along  a  month  by  month  timeline. 
The  dates  of  the  five  exercises  during  OC3  are  marked  by  below  the  central  rectangle. 
The  objectives  of  OC3,  based  upon  requirements  and  technological  characteristics,  are 
shown  to  the  right. 

I .  Requirements  for  OC3 

The  eight  OC3  objectives  to  be  completed  during  the  final  20-month  period  of  the  DCP 
experiment  were  to:  (1)  develop  a  mini-staff  duty  station  for  G3  ACTOs  and  divisional  use, 
<  2)  modify  equipment  for  use  in  vehicles,  (3)  develop  interface  requirements  for  other  C2 
systems,  (4)  develop  interactive  graphics,  (5)  refine/enhance  the  database 


management  system,  (6)  field  a  16-bit  communications  gateway  station.  (7)  prepare  V 
Corps  for  self-sufficiency,  and  (8)  complete  the  V  Corps  DCP  concept. 

a.  Develop  a  Mini-Staff  Duty  Station  for  G3  ACTOs 
and  Divisional  Use 

Four  ACTO  SDSs  were  demonstrated  for  acceptance  testing  during  OC2. 
Based  on  overwhelming  staff  action  officer  acceptance,  DNA  decided  that  all  non-VBDS 
staff  duty  stations  for  the  8ID  should  be  converted  to  the  mini-SDS.  In  addition,  once  the 
new  16-bit  gateways  were  fielded,  the  older  Apple  gateways  would  be  converted  into  mini- 
SDSs  for  distribution  to  other  units.  [Ref.  17:p.  II-5] 

b.  Modify  Equipment  for  Use  in  Vehicles 

The  8ID  experienced  recurring  hardware,  grounding,  and  power  problems 
throughout  OC2.  During  Exercise  REFORGER  82,  8ID  tested  UPSs  with  field  generators 
and  German  commercial  power  to  determine  whether  these  devices  could  protect  SPADS 
equipment.  [Ref.  14:pp.  1-6]  During  the  8ID  CPX  in  December  1982,  there  were  a  large 
number  of  failures  on  the  local  area  network,  within  the  SDSs  and  at  the  gateways. 
Numerous  interface  cards  and  integrated  circuit  chips  were  destroyed  by  power  surges, 
grounding  problems,  and  unbalanced  electrical  loads.  [Ref.  18:pp.  8-14] 

DNA  specified  that  hardware  solutions  would  be  implemented  to  protect  the 
8ID  SPADS  equipment  when  it  was  operating  in  the  M-4  vans. 

c.  Develop  Interface  Requirements  for  Other  C2  Systems 

The  successes  during  past  exercises  produced  the  requirement  for 
interconnectivity  with  other  Army  C2  systems  [Ref.  14:p.  9]  The  requirements  for  OC3 
were  to  develop  rigorous  interface  specifications  or  protocols  for:  (1)  MICROFIX,  (2)  the 
Tactical  Computer  Terminal  (TCT),  (3)  TACFIRE  and  (4)  the  Target  Analysis  and 
Planning  (TAP)  program.  [Ref.  8:pp.  33-35] 


d.  Develop  Interactive  Graphics 


During  past  operational  capability  cycles  there  had  been  limited  success  with 
the  timely  production  of  manually  generated  decision  graphics.  This  shortfall  would  be  the 
impetus  for  a  software  effort  that  integrated  information  from  SPADS  DBMS  and  Briefing 
to  produce  an  automatically  updating  decision  graphic  for  Current  Situation. 

e .  Refine  or  Enhance  the  Database  Management  System 

V  Corps  G3  Operations  and  several  other  staff  sections  had  expressed  a 
need  for  data  bases  with  additional  functions.  The  G3  had  also  requested  that  instructions 
be  given  to  key  V  Corps  staff  personnel  on  the  construction  of  data  bases  using  SPADS 
DBMS.  [Ref.  16:p.  III-6] 

During  Caravan  Guard  IV  staff  users  suggested  that  more  rapid  data  base 
updates  could  be  accomplished  in  future  exercises  if  the  data  bases  were  updated  directly, 
rather  than  through  information  passed  by  electronic  mail  [Ref.  17:p.  1-4]. 

These  two  user  requirements  would  be  implemented  during  OC3. 

f.  Deploy  a  16-bit  Communications  Gateway  Station 

The  original  8-bit  gateway  could  not  meet  the  needs  of  the  V  Corps  DCP  by 
the  end  of  OC2.  Task  1 1  of  the  SOW  required  the  developer  to  convert  the  8-bit  gateway 
code  to  the  16-bit  microcomputer  selected  for  the  new  gateway.  New  CGSs  were  needed 
to  increase  the  speed  of  message  traffic  transmission  and  reception,  to  reduce  LAN  and 
hard  disk  contention,  and  to  produce  more  efficient  management  of  the  module's  computer 
resources.  [Ref.  8:p.  33] 

g.  Prepare  V  Corps  for  a  Successful  Transition  to 

Seif-sufficiency 

DNA  selected  V  Corps  to  be  the  testbed  for  the  DCP  experiment  in  1981. 
The  agency  had  provided  all  guidance  and  logistics,  as  well  as  most  of  the  funding, 
through  the  end  of  OC2.  One  of  the  conclusions  of  the  Caravan  Guard  In-progress  Review 
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(,IPR)  was  that  V  Corps  should  develop  a  plan  to  manage  SPADS  as  an  Army  C2  program. 
The  V  Corps  Charter,  presented  in  Chapter  IV,  would  be  the  starting  point  for  the  transition 
to  self-sufficiency.  [Ref.  17:pp.  II- 14  - 11-16] 

h .  Complete  the  V  Corps  DCP  Concept 

The  completed  V  Corps  DCP  concept  would  consist  of:  (1)  horizontal 
command  and  information  flow  throughout  the  dispersed  corps  modules,  and  (2)  vertical 
command  and  information  flow  from  the  corps  commander  to  his  immediate  subordinate 
combat  commanders  in  the  3AD,  8ID,  1 1ACR,  and  12CAG. 


2  .  Tasks  from,  the  Statement  of  Work 

a.  Task  15:  Provide  Extended  Exercise  Support 

Test  objectives  and  key  data  elements  needed  for  the  evaluation  of  V  Corps 
DCP  exercises  were  to  be  identified  for  each  CPX,  FTX,  etc.  so  that  systems  evaluators 
from  supporting  Army  agencies  could  monitor  the  progress  of  SPADS  during  OC3. 

b.  Task  16:  Provide  Continued  Hardware  and  Software 

Development  for  the  DCP  Program 

The  developer  was  to  accomplish  two  tasks:  (1)  refine  or  correct  software 
problems  identified  in  past  exercises,  and  (2)  continue  16-bit  microprocessor  CGS 
development. 

c.  Task  17:  Provide  Exercise  Support 

In  July  1983  TRADOC  provided  $1.4  million  to  provide  support  to  the  V 
Corps  and  8ID  DCP  programs  through  the  second  quarter  of  fiscal  year  84  (FY  84).  The 
Army  Command  and  Control  Initiative  Program  (TACIP)  was  to  monitor  the 
accomplishment  of  this  task.1 


interview  between  R.  Laird,  Lieutenant  Colonel,  USA,  Defense  Nuclear  Agency, 
Alexandria,  Virginia  and  author,  17-18  December  1987. 


d.  Task  18:  Software  Support 

The  developer  was  tasked  to:  (1)  continue  development  of  the  16-bit 
communications  gateway,  (2)  continue  user  identification  requirements,  and  (3)  customize 
software  for  division  usage. 

e .  Task  19:  On-site  Support  for  the  DCP  Program 

This  task  required  the  developer  to  establish  an  on-site  support  facility  at  V 
Corps  Headquarters  in  Frankfurt,  West  Germany.  The  facility  would  be  completely 
furnished  with  tools,  documentation,  and  spare  pans  and  be  supported  by  an  integrated 
logistics  support  plan.  Two  full-time  employees,  a  software  developer  and  a  system., 
integrater,  were  to  provide  on-site  support  40  hours  per  week  in  garrison  and  as  required 
during  exercises.  [Ref.  8:p.  20] 

f.  Task  20:  Continued  Support 

The  first  part  of  this  task  would  provide  software  support  and  corrections 
during  exercises.  It  would  also  improve  the  SPADS  database  management  system  and 
integrate  the  DBMS  with  automatic  graphics  output.  It  would  investigate  the  display  of 
improved  decision  graphics  information  and  require  that  the  SPADS  communication 
software  be  modified  to  implement  both  TCT  and  MICROFIX  protocols. 

g.  Task  21:  Field  a  16-bit  Communication  Gateway  Station 

The  developer  was  required  to  accomplish  the  following  at  V  Corps:  (1) 
field  a  16-bit  microcomputer-based  CGS,  (2)  install  the  16-bit  CGS,  and  (3)  conduct 
training  for  the  new  gateway. 

h.  Task  22:  Transition  Training  and  Support 

This  final  task  of  OC3  was  supposed  to  assist  V  Corps  and  8ID  SPADS 
users  in  preparing  to  be  self-sufficient  after  FY  84.  The  developer  was  required  to:  (1) 
conduct  pre-exercise  support  and  evaluation  and  assist  commander  and  staffs  in  identifying 
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SPADS  objectives  and  performance  standards  based  upon  such  objectives;  (2)  conduct 
technical  support  for  Caravan  Guard  V  and  REFORGER  84;  (3)  publish  post-exercise 
reports;  (4)  conduct  an  expanded  training  program  at  V  Corps;  and  (5)  update  all 
documentation,  revise  the  User’s  Manual,  and  produce  a  free-standing  reference  flip  card 


TRADOC  provided  $350,000  for  this  task  in  February  1984;  the  first 
$190,000  was  to  be  used  by  30  September  1984  and  the  final  $160,000  used  by  30 
September  1985. 2 


The  8ID  developed  a  separate  statement  of  work  to  support  the  plans  that  they 
had  developed  for  REFORGER  84  [Ref.  20:pp.  1-2].  (These  plans  are  discussed  in  detail 
later  in  this  chapter.) 

a.  Task  1:  Develop  a  Hardwire  Interface  Between  a  SPADS 
Workstation  and  a  TACFIRE  System 

This  task  required  that  a  MILSTD  188  interface  to  TACFIRE  be  developed.  This 
interface  had  to  be  capable  of  transferring  data  files  between  the  TACFIRE  and  SPADS 
systems  as  well  as  passing  free  text  from  SPADS  to  TACFIRE. 

b.  Task  2:  Develop  a  System  for  Automatically  Updating  SPADS 
Position  Location  Data  Bases  Based  Upon  Electronic 
Information  Provided  by  TACFIRE 

The  developer  was  required  to  develop  a  system  to  receive  and  interpret  the 


data  base  information  coming  from  TACFIRE  through  the  hardwire  interface.  The  SPADS 
system  was  required  to  insert  this  data  into  a  PDBase  relation  within  the  DBMS. 


c.  Task  3:  Provide  On-site  Exercise  Support  to  8ID  During 
REFORGER  84 

Support  was  to  be  provided  at  the  pre-REFORGER  CPX  as  well  as 
throughout  REFORGER  84.  The  8ID  personnel  were  to  be  trained  on  the  following 
SPADS  n3  capabilities:  briefing,  graphics  systems,  and  the  DAViD  videodisc  system. 

4 .  PNA  Design  Principles 

The  third  operational  capability  continued  to  follow  the  seven  DNA  design 
principles  specified  in  OC1  and  OC2  [Ref.  8:p.  16]. 

5.  Exercise  Objectives  during  OC3 

V  Corps  would  use  SPADS  during  Exercise  REFORGER  83  to  maintain 
exercise  control  over  the  "orange"  (8ID)  and  "blue"  (3AD)  forces  from  the  corps  field  site 
at  Fliegerhorst  Kaseme  in  Hanau.  V  Corps  would  establish  one  CBC  for  each  force.  8 ID 
was  expected  to  use  SPADS  to  control  the  "orange"  forces  throughout  the  exercise.  3AD, 
using  equipment  borrowed  from  V  Corps,  would  employ  SPADS  for  the  first  time.  The 
3AD  SPADS  objectives  were  to  provide  friendly  situation  data  to  V  Corps  and  to  3AD 
RAOC  using  the  BIRS  data  base,  and  to  pass  message  traffic  among  the  3 AD  main  CP, 
3AD  RAOC,  and  V  Corps  using  EMS.  [Ref.  20:p.  1-2] 

The  primary  SPADS  objective  for  Exercise  Able  Archer  83  was  the  acceptance 
test  of  the  new  16-bit  Corvus  Concept-based  CGS.  This  new  gateway  had  been 
demonstrated  during  REFORGER  83.  A  secondary  objective  for  V  Corps  was  to  check 
out  internal  operating  procedures  using  SPADS.  [Ref.  20:p.  II- 1] 


3The  USAREUR  Distributed  Decision  Aids  System  (UDDAS)  introduced  in  March 
1984  became  known  as  SPADS  II. 


4  Corvus  and  Corvus  Concept  are  registered  trademarks  of  Corvus  Computers. 


The  primary  SPADS  objective  for  Exercise  Crested  Eagle  84  was  to  field  and  test 
the  full  deployment  of  the  16-bit  communication  gateway  station  and  associated  software. 
A  secondary  objective  of  the  exercise  was  to  evaluate  a  new  V  Corps  videodisc  and  the  new 
VBDS  software  required  to  integrate  the  video  platter  into  the  SPADS  system.  [Ref.  20:p. 

in-1] 

The  SPADS  objectives  for  Exercise  Caravan  Guard  V  were  to  check  out  the 
software  corrections  or  modifications  that  V  Corps  had  mandated  at  the  Exercise  Crested 
Eagle  IPR  in  March,  and  to  evaluate  the  development  of  automatic  graph  creation  that  V 
Corps  had  requested  during  Exercise  Able  Archer  83.  [Ref.  20:p.  V-l] 

The  8ID  objectives  for  Exercise  REFORGER  84  were  to  implement  a  SPADS- 
TACFIRE  interface,  use  the  USAREUR  Distributed  Decision  Aids  System  (UDDAS) 
software  to  display  the  exercise  information  at  the  Umpire  Control  Center  (UCC),  and  use 
SPADS  to  support  the  three  Area  Control  Centers  (ACC). 

The  primary  SPADS  objective  for  Exercise  Wintex  85  was  to  support  the  V 
Corps  CPX  which  consisted  of  the  V  Corps  Headquarters,  two  division  headquarters,  and 
the  1 1 ACR  [Ref.  22:p.  7]  A  secondary  objective  was  to  provide  the  TCATA  test  team  the 
opportunity  to  evaluate  the  V  Corps  DCP  shortly  after  the  conclusion  of  OC3 
[Ref.  22:p.  1]. 

The  two  TCATA  test  issues  for  the  evaluation  during  Wintex  85  were:  (1)  to 
assess  the  assistance  provided  to  the  commander  and  staff  by  the  C2  system,  and  (2)  to 
assess  the  assistance  provided  to  the  C2  function  by  SPADS  and  document  key 
characteristics  of  that  system  [Ref.  22: p.  5] 

Table  17  presents  an  overview  of  the  exercises  and  objectives  for  OC3. 
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B  .  BOUNDING  THE  C2  SYSTEM 

This  section  uses  the  same  approach  as  Chapters  3  and  4.  First,  the  workstation 
bounds  of  the  hardware  and  software  are  described.  Then  the  module  level  describes  the 
SPADS  entities  and  structure  within  the  confines  of  one  modular  command  post.  Finally, 
the  network  level  defines  the  SPADS  system  within  the  procedural,  geographical,  and 
hierarchical  bounds  that  interconnect  the  modules. 


a.  Hardware 

Although  no  new  hardware  was  introduced  at  the  workstation  level  during 
OC3,  some  previously  tested  components  were  removed  from  the  staff  duty  station. 
Neither  the  graphics  tablet  nor  the  joystick  were  rugged  enough  for  field  use  and  were 
removed  without  replacements. 

After  the  successful  demonstration  of  the  ACTO  mini-SDS  during  OC2,  the 
decision  was  made  that  only  mini-SDSs  would  be  fielded  for  the  remainder  of  the 
experiment.  The  mini-SDS  had  all  the  capabilities  of  the  original  SDS  except  that  it  could 
not  support  the  VBDS  functions. 

b.  Software 

Software  development  during  OC3  was  split  between  upgrading  older 
software  to  take  advantage  of  the  new  gateway  capabilities  and  fielding  the  interactive 
graphics  software.  The  Data  Automated  Graphics  and  Retrieval  (DAGMaR)  system, 
introduced  in  1984,  provided  the  staff  user  with  greater  control  over  graphics  and  overlay 
capability.  DAGMaR  enabled  the  staff  officer  to  link  spreadsheets,  data  bases,  and 
decision  graphics  capabilities  to  produce  automatically  updating  briefing  slides  that  could  be 
incorporated  in  Current  Situation. 


TABLE  17 

OVERVIEW  OF  OPERATIONAL  CAPABILITY  3 


Principle  Objective(s) 


Date 


Exercise  REFORGER  83 

•  3rd  Armored  Division  added  to  system 

•  Automated  data  links  V  Corps  -  8ID  -  3AD 

•  Mini  Staff  Duty  Stations  fielded 

•  Upgraded  LAN  for  field  use 


Sept.  1983 


Exercise  Able  Archer  83 


Nov.  1983 

16-bit  communications  gateway  demonstration 


Exercise  Crested  Eagle  84 


March  1984 

16-bit  communications  gateways  fielded 

New  video  disk  software  demonstrated 

V  Corps  CTOC  linked  through  SPADS  to  the  USAREUR 

Distributed  Decision  Aid  System  (UDDAS) 

into  the  CENT  AG  Main  CP 

TCT-SPADS  demonstration  at  CENTAG 


Exercise  Caravan  Guard  V 


May  1984 

Modifications  to  electronic  mail  system,  text  editor,  data 
base  management  system,  video  battlefield  display  system, 
and  communications  gateway  software 
Implementation  of  TCT  protocol  on  the  16-bit  CGS 
1 1th  Armored  Cavalry  Regiment  added  to  system 


Exercise  REFORGER  84 


Sept.  1984 

Integrated  Data  Automated  Graphics  and  Retrieval 
(DAGMar)  system  software  delivered 
Implementation  of  TACFIRE  protocol  on  the  16-bit  CGS 
8ID  Engineer/Obstacle  data  base  implemented 


Exercise  Wintex  85 


March  1985 

External  evaluation  of  all  OC3  capabilities  by  TCATA 


During  Exercise  REFORGER  83,  V  Corps  staff  users  had  requested  the 
feasibility  of  having  Briefing  and  Current  Situation  graphs  automatically  updated  by  the 
DBMS.  With  the  original  software,  the  SPADS  operator  had  to  painstakingly  edit  each 
graphic  slide  with  every  new  update.  DAGMar,  introduced  in  1984,  significantly 
simplified  the  creation  and  updating  of  spreadsheet-based  graphs.  Once  the  user  created 
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his/her  fundamental  graph,  the  program  automatically  generated  a  current  version  of  the 
graph  every  time  the  data  base  was  updated.  These  automatically  created  decision  graphics 
were  transmitted  to  all  other  modules  in  the  network  for  viewing  in  Current  Situation. 
[Ref.  20:p.  VI-3] 

The  text  editor  and  EMS  were  integrated  during  the  period  between 
REFORGER  83  and  Crested  Eagle  84.  This  integration  removed  unnecessary  options, 
made  the  EMS  functions  flow  more  smoothly,  and  allowed  the  operator  to  perform  all 
message-handling  functions  without  leaving  EMS.  [Ref.  20:p.  Ill- 15] 

The  following  corrections  and  enhancements  were  made  to  the  EMS 
software  immediately  prior  to  Exercise  Caravan  Guard  V  [Ref.  20:p.  HI- 15]: 

1 .  Messages  could  be  sent  to  more  than  25  users  simultaneously 

2 .  Users  could  no  longer  create  illegal  volumes 

3 .  Duplicate  messages  were  no  longer  sent  to  addressees 

4 .  The  mail  delete  option  was  speeded  up 

5 .  Mail  sent  without  an  addressee  no  longer  caused  the  gateway  to  stop 

6.  Action  and  information  addressee  were  listed  in  "plain  English"  and  selected 
addressees  were  printed  on  each  message 

7 .  An  escape  option  was  built  in  for  use  in  the  Read  Mail  option 

8 .  More  than  ten  modules  could  be  addressed 

9 .  Forwarded  mail  was  no  longer  returned  to  the  sender 

A  major  objective  of  Exercise  REFORGER  83  had  been  to  use  the  BIRS 
and  OB  data  bases  for  the  first  time  to  exchange  friendly  and  enemy  information  among  V 
Corps  units  at  different  echelons.  During  Exercise  Crested  Eagle  84,  the  two  data  bases 
were  used  even  more,  resulting  in  G3  Operations  and  G3  Plans  identifying  areas  that 
required  timely  correction  before  the  next  exercise.  The  following  refinements  were 
implemented  immediately  before  Caravan  Guard  V  [Ref.  20:p.  Ill- 16]: 


1 .  A  global  update  capability  was  created 

2 .  V  Corps  engineer  data  bases  were  developed 

3 .  Time  required  to  print  out  BIRS  and  OB  reports  was  reduced 

4.  An  "as  of  DTG"  reporting  format  for  BIRS  and  OB  was  added 

Following  Exercise  REFORGER  84,  V  Corps  SPADS  users  developed  an 
updated,  friendly  status  data  base  called  BIRS  II.  This  was  based  upon  the  identified 
requirements  of  G3  Operations,  G3  Plans,  G4  Operations,  and  FSE.  Table  5.2  displays 
the  BERS  II  input  fields  [Ref.  22:p.  56] 

Up  until  Exercise  Crested  Eagle  84,  the  text  editor  SPADS  used  was  a 
commercially  produced  Pascal  text  editing  package.  SPADS  users  had  noted  recurring 
problems  in  this  text  editor.  Additionally,  the  editor  no  longer  met  V  Corps  requirements. 
A  new  text  editor  was  integrated  with  EMS.  Following  Exercise  Crested  Eagle  84,  SPADS 
users  requested  the  following  fixes  and  refinements  [Ref.  20:p.  HI- 16]: 

1 .  Eliminate  the  appearance  of  control  characters  within  text 

2 .  Insert  a  spooling  capability  so  that  all  output  does  not  go  to  the  local  printer 

3 .  Develop  a  List  Directory  capability  so  that  users  can  scan  their  own  workspaces  for 
file  names 

A  secondary  objective  of  Exercise  Crested  Eagle  had  been  to  evaluate  a  new 
videodisc  and  the  associated  software.  The  G3  staff  users  recommended  that  the  following 
capabilities  be  included  within  VBDS  as  soon  as  possible  [Ref.  20:p.  m-17]: 

1 .  Put  six-digit  coordinates  in  both  VBDS  and  the  DBMS 

2.  Improve  the  ability  to  "hook"  units  at  100  and  200  kilometers  and  insert  a  two-  to 
five-kilometer  hook  radius 
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TABLE  18 

BATTLEFIELD  INFORMATION  REPORTING  SYSTEM  II 

(BIRS  II)  INPUT  FIELDS 


1.  UNIT: _ 

2.  _  3. _ 

6.  DATE: _ Z _ 

8.  ENEMY  ACTION: 

9.  MISSION: _ 

10.  LEAVE  BLANK. 

11.  LEAVE  BLANK. 

12.  LEAVE  BLANK. 

13.  TAC  CP: 


4.  TYPE: _ 

(DDHHHHZMMMYY) 


5.  SIZE: _ 

7.  OPCON:. 


1.  UNIT: _ 

PERSONNEL 
TANKS  M60 
TANKS  Ml 
CFV 

DRAGON 
TOW  LNCHR 


OPERATIONAL  STATUS 

2.  DATE: _ Z _  (DDHHHHZMMMYY) 

Q/H  AVL  EVAL  REASON  AS  OF  DAY/TIME 


3. 

4. 

5. 

11. 

6. 

7.  /  Z 

Z 

8. 

9. 

10. 

•— 

12. 

13. _ / 

14. 

15. 

16. 

17. 

18. 

19. _ / 

z 

20. 

21. 

22. 

23. 

24. 

25. _ / 

z 

26. 

27 

28. 

29. 

30. 

31.  /  Z 

32. 

33. 

.  34.. 

_ 35. 

36.. 

37.  /  Z 

1.  UNIT: 

2. 

DATE: 

Z 

(DDHHHHZMMMYY) 

REO  O/H 

AVL 

EVAL  RF.ASl 

DN  AS  OF  DAY/TIME 

ATKHEL 

3.  4. 

5. 

6.  7. 

8.  /  Z 

155MM  HOW 

9.  10. 

11. 

12.  13. 

14.  /  Z 

8INHOW 

15.  16. 

17. 

18.  19. 

20.  /  Z 

MLRS 

21.  22. 

23. 

24.  25. 

26.  /  Z 

LANCE 

27.  28. 

29. 

30.  31. 

32.  /  Z 

REMARKS: 

33. 

34. 

35. 

37.  CDR'S  OVERALL  EVALUATION  OF  UNIT'S  CAPABILITY  IS:_(COLOR) 

38.  REASON:  _  ....  _  _ 


The  software  capabilities  of  SPADS  were  virtually  completed  by  Caravan 
Guard  V.  DAGMaR  was  introduced  in  three  stages  over  the  next  three  months.  The 
integration  of  DBMS,  the  chart  editor,  and  the  spreadsheet  was  accomplished  by  October 


1984. 


SPADS  developed  four  information  exchange  capabilities:  word  processing, 


electronic  mail,  graphics,  and  a  common  data  base.  Word  processing  provided  the 
capability  to  prepare,  edit,  update,  and  print  text  information  e.g.,  plans  and  orders. 
Electronic  mail  provided  the  means  to  transmit  and  receive  the  following  information  within 
and  between  modules.  Commander's  estimate,  FRAGO,  FLOTREP,  SITREP,  OPORD, 
INTSUM,  SPOTREP  and  Weather.  The  graphics  data  were  stored  locally;  the  overlay 
data,  which  were  superimposed  on  graphic  data  or  videodisc -generated  maps,  were 
transmitted  within  and  between  modules.  The  common  data  base  at  each  module  was 
partitioned  according  to  staff/echelon  functions;  users  input  data  into  their  partitioned  area 
of  the  common  data  base;  and  the  input  data  was  automatically  replicated  in  common  data 
bases  at  other  module  locations. 

These  information  exchange  capabilities  were  supported  by  the  following 
software  capabilities  of  SPADS.  BIRS  gave  the  SPADS  users  information  on  friendly 
units  and  was  available  through  the  DBMS  at  all  staff  duty  stations.  Similarly,  OB 
provided  information  on  enemy  units  for  all  users.  EMS  provided  intra-  and  inter-module 
text  transfer  for  all  SPADS  users.  VBDS  was  available  at  one  SDS  in  each  module  to 
provide  display  of  friendly  and  enemy  force  data  and  situation.  Spreadsheet  provided 
processing  for  worksheet  calculations  and  transmission  for  all  users.  Current  Situation 
was  available  at  every  SDS.  DAGMaR  provided  decision  support  by  integrating  the 
DBMS,  spreadsheet,  and  decision  graphics  at  all  staff  duty  stations.  [Ref.  19:p.  50] 


In  addition,  SPADS  developed  five  decision  support  capabilities  during  the 
three  operational  capabilities.  A  relational  database  management  system  provided  the 
means  to  extract  information  from  large  data  files  by  querying  of  a  single  file  or  across 
multiple  files.  The  correlation  of  geographically  indexed  reports  and  data  bases  with  map 
backgrounds  provided  the  capability  to  automatically  display  data  such  as  unit  locations  on 
a  single  overlay  of  specially  prepared  maps  shown  on  the  color  monitor.  Map-to-photo 
correlation  allowed  quick  retrieval  of  photographs  stored  on  the  videodisc  by  pinpointing 
the  location  of  the  desired  photograph  on  the  map  display  being  viewed  through  a  series  of 
crosshair  overlays.  Spreadsheet  models  provided  the  means  to  perform  mathematical 
calculations  related  to  status  monitoring  and  projection.  The  execution  of  functional  area 
algorithms  supported  individual  staff  functions  such  as  maneuver,  combat  service  support, 
target  planning,  and  force  comparison. 


a.  Hardware 

The  significant  advancement  at  the  module  level  was  the  introduction  of  the 
16-bit  communications  gateway  station.  The  16-bit  gateway  was  demonstrated  during 
Exercise  REFORGER  83  and  successfully  underwent  acceptance  testing  during  Exercise 
Able  Archer  83.  Prior  to  Exercise  Crested  Eagle  84  all  SPADS  Apple  EI+  8-bit  gateways 
were  replaced  by  the  new  16-bit  Corvus  Concept-based  gateways.  The  new  gateway 
implementation  followed  the  seven  layer  ISO-OSI  model.  Table  19  presents  an  overview 
of  the  SPADS  implementation  of  this  model  [Ref.  20:p.  II-5]. 
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TABLE  19 

SPADS  IMPLEMENTATION  OF  THE  ISO-OSI  MODEL 


Seven  Layers 


MiiiimiTiiLB-rniii  mb  mu 

7 .  Application 

Mail,  File  Transfer,  Data  Base  Update 

6.  Presentation 

Conversion  to  network  format; 

End  delivery 

5.  Session 

Login  Validation 

4  Transport 

— 

3 .  Network 

Message  Switching 

2.  Link 

Variable  Frame  Size;  Windowing; 
CRC  checksum 

1 .  Physical 

RS232  Asynchronous 

The  new  gateway  controlled  the  local  network  within  a  module  and 
provided  users  with  the  capability  to  send  both  messages  and  files  to  other  users  within  the 
module  or  to  users  in  other  modules  via  the  tactical  communications  system.  The 
components  of  the  new  gateway  were  [Ref.  20:pp.  III-3,  HI-6]: 

1 .  Two  Corvus  Concept  16-bit  microcomputers 

2 .  A  modem  for  each  communication  link  (one  microcomputer  could  handle  up  to  four 
links) 

3 .  An  8-inch  floppy  disk  drive 

4.  A  full  function  keyboard 

5.  A  monitor  with  a  video  switch  that  permitted  viewing  of  either  microcomputer’s 
contribution  to  the  CGS 

6 .  Two  cases  that  permitted  operating  the  equipment  without  removing  it  from  the  cases 
and  that  provided  protection  for  the  equipment  when  it  was  transported 
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One  of  the  microcomputers  controlled  the  module  network  and  was  called 
the  network  control  processor  (NCP).  The  other  microcomputer  provided  the 
communications  interface  and  was  called  the  communications  link  processor  (CLiP);  the 


CLiP  supported  four  external  data  links. 

The  new  gateway  hardware  alleviated  the  following  problems  and 
weaknesses  in  the  old  Apple  11+  CGS  [Ref.  20:p.  ni-6]: 

1 .  Excessive  size  and  weight 

2 .  Excessive  hard  disk  accesses  for  program  chaining  and  polling  for  files 

3 .  Inadequate  queuing  for  files 

4.  Nearly  full  processing  and  memory  capacities 

The  16-bit  gateway  was  one  third  the  size  and  one  fourth  the  weight  of  the 
old  gateway.  Hard  disk  accesses  were  reduced  by  70  to  80  percent.  Improved  file  queuing 
resulted  in  reduced  system  manager  intervention  and  the  prevention  of  message  loss. 
Approximately  50  percent  of  the  processing  capacity  and  30  percent  of  the  memory  capacity 
were  in  use  on  the  new  CGS,  as  opposed  to  both  capacities  being  nearly  100  percent  full 
on  the  older  gateway.  [Ref.  20:p.  III-6] 

The  Apple  equipment  that  was  recovered  from  the  older  gateways  was 
retrofitted  to  create  26  mini-staff  duty  stations,  four  shared  output  stations  and  two  mass 
storage  stations.  The  resulting  configurations  were  placed  in  the  3 AD  and  the  1 1 ACR  to 
provide  complete  interconnectivity  for  the  V  Corps  DCP.  [Ref.  20:pp.  III-6,  HI- 14] 

Table  20  presents  an  overview  of  the  hardware  components  of  the  16-bit 
communications  gateway  station. 


TABLE  20 

16-BIT  COMMUNICATIONS  GATEWAY 
STATION  (CGS)  HARDWARE 


Microcomputer 

Processor 


Corvus  Concept  I 

(One  each  for  NCP  and  CLiP) 

Motorola  MC-68000 

•  32  bit  data 

•  24  bit  memory 

•  16  bit  data  bus 


Memory 

256K 

Expandable  to  1  Mbyte 

Interfaces 

RS-232C  19,2000  baud 

RS-422  1  Mil  baud 

Monitor 

15  inch  CRT, 

•35  MHz 

•  Bit  mapped  display 

Floppy  Drive 

8  inch  1  Mbyte 

Detached  keyboard 

Modem 

Racal-Vadic  (up  to  four  per  CLiP) 

External  connections 

Four  2-wire  connections 

Universal  power  supply 

Supports  microcomputers, 
monitor  and  modems 

b.  Software 

The  three  major  functions  of  the  new  gateway  were  an  upgraded  EMS,  new 
common  area  management,  and  substantially  more  powerful  network  management.  The 
new  EMS  selected  routing,  prepared  headers,  sent  messages  and  packages  to  authorized 
users,  received  and  analyzed  messages,  and  delivered  messages  and  packages  to  authorized 
users.  The  common  area  management  (CAM)  automatic uiv  updated  common  area  within 


gras 


the  local  network,  routed  updates  to  remote  modules,  and  allowed  users  read-only  access  to 
common  area  volumes  of  all  authorized  users.  The  network  management  administered  user 
access  to  the  network,  administered  the  network  topology,  provided  statistical  monitoring 
or  network  usage,  and  performed  user  service  requests.  [Ref.  20:p.  El- 14] 

Figure  5.2  displays  an  overview  of  the  three  functional  areas  of  the 
communications  gateway  station  [Ref.  20:p.  EI-8]. 

During  Exercise  Crested  Eagle  84,  SPADS  system  managers  identified  the 
following  problems  with  the  NCP  code  [Ref.  20:p.  El- 17]: 

1 .  The  NCP  sometimes  stopped  and/or  fatally  crashed  when  processing  BIRS  and  OB 
updates 

2 .  The  NCP  needed  a  distinct  audio  or  visual  alarm  to  signal  fatal  errors 

3.  A  capability  was  required  to  automatically  reinstate  users  when  the  NCP  was 
restarted  after  stopping 

By  the  end  of  Exercise  Caravan  Guard  V  all  but  six  of  the  software 
modifications  mandated  by  V  Corps  had  been  installed.  The  most  significant  remaining 
modifications  related  to  the  number  of  staff  duty  stations  that  could  be  logged  onto  a  local 
network  and  the  number  of  total  modules  permitted  in  the  network.  Up  to  this  time,  V 
Corps  could  only  connect  ten  SDSs  to  a  local  network  and  ten  CGSs  to  the  global  network. 
The  final  modifications  increased  the  number  of  users  in  the  global  network  to  10,000,  the 
only  restriction  being  that  a  maximum  of  255  staff  duty  stations  could  be  logged  on  the 
LAN.  This  increase,  together  with  the  elimination  of  restrictions  pertaining  to  the  number 
of  modules,  provided  V  Corps  with  immense  flexibility  for  employing  SPADS  in  future 
configurations.  [Ref.  20:p.  VI- 12] 


Figure  5.2.  Communications  Gateway  Station  Functional  Diagram 


Following  Exercise  REFORGER  84  two  final  upgrades  were  made  to  the 
gateway  software  [Ref.  20:p.  VI- 14]: 

1 .  An  Initializer  was  introduced  that  replaced  the  Gateway  Manager  and  ran  on  the  same 
microcomputer  as  the  NCP 

2 .  Modifications  were  made  to  the  NCP  and  the  CLiP  that  resulted  in  full,  TCT  free  text 
message  interface  with  SPADS,  allowed  up  to  four  CLiPs  per  module  (permitting  16 
external  communications  links),  and  moved  the  overflow  and  queuing  functions 
from  the  CLiP  to  the  NCP. 

3.  Network  Level  Bounding 

Based  upon  the  new  gateways  and  the  dispersal  of  equipment  to  3AD  and 
11ACR,  the  V  Corps  DCP  had  spread  throughout  its  entire  geographic  area  and  had 
established  interconnectivity  from  the  USAREUR/CENTAG  level  down  to  its  principal 
combat  units.  Figure  5.3  displays  the  V  Corps  SPADS  network  that  was  possible  during 
OC3. 

4.  Economic  Bounding 

The  total  funding  for  SPADS  through  FY  84  had  been  $7.2  million.  Table  21 
presents  an  overview  of  both  the  equipment  costs  and  contractor  support  costs  during 
OC35  . 

C.  C2  SYSTEM  ARCHITECTURE 
1 .  Workstation  Level  Integration 

During  OC3  only  one  new  software  implementation  produced  new  opportunities  for  staff 
interaction.  However,  since  DAGMaR  capabilities  were  gradually  phased  into  SPADS,  the 
spreadsheet  and  DAGMaR  can  be  considered  two  separate  functions.  The  next  two  figures 
present  the  integration  of  the  two  new  software  functions  with  the  C2 


5  Interview  with  LTC  Laird,  17-18  December  1987. 


SPADS  Network  During  OC3 


TABLE  21 

ECONOMIC  BOUNDING  DURING 
OPERATIONAL  CAPABILITY  3 


EQUIPMENT  COSTS 


16-Bit  Communications  Gateway  Station 
Staff  Duty  Stations 

•  SDS  with  Video  Package 

•  SDS  without  Video  Package 

•  Mini  SDS  with  Medium  Speed  Printer 
Mass  Storage  Stations 

•  Large  Package  20  MByte  Hard  disk 

•  Small  Package  20  Mbyte  Hard  disk 


$12,230.00 

$11,800.00 
$  5,860.00 
$  5,640.00 

$  8,050.00 
$  5,750.00 


CONTRACTOR  SUPPORT  COSTS 


Exercise  support  per  week  $  2,547.00 

per  contractor  (Europe) 

Maintenance  of  System  10%  of  Component  Costs 

Maintenance  support  per  week  $  1,007.00 

per  technician  (Europe) 

Module  Transportation  Costs  $  900.00 

(Approx.  $  10/pound  to  Europe) 

TOTAL  FUNDING  THROUGH  FY  84  $7.2  million 


system  and  the  C2  process.  First,  figure  5.4  displays  the  integration  of  system,  process. 


and  function  with  the  spreadsheet.  Then  figure  5.5  shows  the  integration  of  entities, 
structure,  and  functions  with  DAGMaR. 
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Figure  5.5.  Integration  of  Data  Automated  Graphics  Manufacture  and  Retrieval 


The  gateway  had  a  strong  integrating  influence  on  the  C2  process  and  functions 
at  the  module  level.  The  concept  of  the  Network  Monitor  Station  (NMS)  was  introduced 
late  in  OC3  to  further  cement  the  unifying  concept  of  the  gateway  and  the  mass  storage 
station  as  one  logical  entity.  Up  to  16  staff  duty  stations  would  be  supported  by  one  NMS 
under  this  plan.  [Ref.  6:p.  F-l] 

The  V  Corps  G3  Operations  clarified  the  role  of  SPADS  equipment  within  a 
DCP  module  [Ref.  6:p.  F-l]: 

The  most  important  function  of  SPADS  is  the  automatic  distribution  of  threat  order  of 
battle  and  friendly  operational  databases  [sic]. ...any  staff  officer/NCO  can  get  instant 
data  and  video  graphics  on  any  unit  and  its  situation  (friendly  and  enemy)  that  has  been 
reported  via  SPADS  without  contacting  the  unit  with  an  individual  request. 

Figure  5.6  represents  the  integrating  influence  of  the  SPADS  Protocol 
Architecture.  This  figure  displays  the  ISO  functional  model  vis-a-vis  the  SPADS 
hardware,  software,  and  staff  user  applications.  [Ref.  20:p.  II-6] 

Despite  their  broad  outlook,  the  DNA  and  Army  agencies  supporting  the  DCP 
never  foresaw  the  new  implementations  that  the  V  Corps  and  8ID  SPADS  users  would 
create  to  overcome  operational  difficulties  in  Germany.  The  last  exercise  of  OC3, 
REFORGER  84,  gives  an  example  of  this  environment.  8ID  was  supposed  to  apply 
Umpire  and  Exercise  control  over  the  VII  Corps  field  exercise.  The  following  paragraphs 
describe  their  unorthodox  application  of  SPADS  and  TACFIRE  to  fulfill  their 
responsibilities. 


V  Corps  Staff  Interaction  Through  SPADS 


Application 


DATA 

MAIL 

GRAPHICS 

BASE 

FILE 

UPDATE 

TRANSFER 

Presentation 


Message 

Deliverer 


Mail/Files 
Data  Base 


Message 

Formatter 


To  Network 
Format 


Session 


Logon 

Validation 


Transport 


Network 


Terminating 

Messages 


Topology 

Manager 


Address 

Manager 


New/Translated 

Messages 


Protocol  Handler 


Outgoing 

Message 

Queue 


Physical 


Protocol 

State 

Transition 

Tables 


Link  Handler 
(Finite  State 
Machine) 


Action  Initiator 


Comm  Card  Driver 


Super  Serial  Card 


•TV 


T 


Xu 


71 UTST 


In  their  role  as  umpires,  8ID  had  wanted  to  use  TACFIRE  to  keep  track  of 
umpire-reported  unit  and  obstacle  locations  and  to  use  this  data  in  conjunction  with  other 
exercise  data  to  develop  briefings.  They  had  also  wanted  to  use  USAREUR's  DAViD  with 
a  large  screen  and  video  projector  to  display  the  exercise  situation.  DAViD  had  been 
developed  for  UDDAS;  UDDAS  was  also  known  as  SPADS  II  because  of  its  similarities  to 
SPADS.  DAViD  performed  the  same  functions  as  the  V  Corps  VBDS  but  provided 
significant  enhancements  in  that  symbols,  data  base  relations,  and  display  features  were  all 
user  definable.  The  SID  needed  the  SPADS  II  workstations  to  run  DA\  D;  these 
workstations  consisted  of  Corvus  Concept  16-bit  microcomputers  and  advanced  high- 
resolution  graphics  devices.  [Ref.  20:pp.  VI- 1,  VI-2] 

The  8ID  objectives  for  REFORGER  84  were  to  use  their  newly  developed 
TACFIRE  interface,  DAViD,  SPADS  II,  and  SPADS  to  support  umpires  throughout  the 
exercise  area.  This  concept  of  operations  included  four  capabilities  not  previously  used  by 
the  8 ID  [Ref.  20:p.  VI-8]: 

( 1 )  The  TACFIRE  interface 

(2)  The  DAViD-generated  large  screen  display 

(3)  The  SPADS  II  workstations 

(4)  An  engineer  obstacle  data  base 

The  most  unorthodox  part  of  their  solution  was  the  selection  of  two  systems  that 
had  not  previously  been  interconnected.  After  8ID  initiated  its  statement  of  work  for  the 
TACFIRE  interface,  significant  coordination  occurred  between  the  TACFIRE  Project 
Manager  in  CECOM,  the  Field  Artillery  School  at  Fort  Sill,  and  the  developer  to  develop 
the  software  for  the  interface  and  to  select  an  appropriate  modem  for  the  hardwire  interface. 
A  synchronous  circuit  card  had  to  be  designed  for  the  gateway  microcomputer. 


Appropriate  software  had  to  be  developed  that  handled  the  Hamming  code  scheme  used  in 
TACFIRE  for  error  detection  and  correction  during  data  transmission.  [Ref.  20:pp.  VI-9  - 
VI- 10] 


3  .  Network  Level  Architecture 

Unlike  the  second  operational  capability,  OC3  focused  on  accomplishment  at  the 
network  level.  The  fielding  of  the  new  gateway  during  Exercise  Crested  Eagle  84 
dramatically  accelerated  V  Corps  DCP  integration.  The  ingenuity  of  operational  planners 
and  users  produced  a  greater  interconnectivity  than  that  conceived  by  the  DNA  or  other 
financial  supporters  of  the  DCP  experiment. 

The  two  perspectives  to  examining  OC3  are  connectivity  and  structure.  OC3 
marked  the  successful  network  interconnections  from  CENTAG  and  USAREUR  down  to 
the  corps  maneuver  elements.  During  this  same  period  V  Corps  finally  attempted  to 
integrate  SPADS  into  the  C2  structure. 

a.  SPADS  Connectivity 

With  the  advent  of  the  new  gateway,  V  Corps  had  the  opportunity  to 
experiment  with  connectivity  between  different  generations  of  gateways.  V  Corps  did  not 
deploy  to  the  field  during  Exercise  Able  Archer  83,  but  set  up  five  modules  at  the 
headquarters  in  Frankfurt.  The  new  CGS  was  used  in  the  CBC  module.  The  Intel,  FSE, 
Plans,  and  Rear  modules  all  used  the  older  gateway.  All  modules  were  interconnected 
through  TASS,  set  up  outside  of  the  headquarters,  to  successfully  communicate  among  the 
modules.  [Ref.  20:p.  II- 1] 

During  Exercise  Crested  Eagle  84  the  CENTAG  main  CP  used  the  newly 


developed  UDDAS.  In  addition  to  its  intra-CP  connections,  it  also  established 
communication  links  to  V  Corps  through  SPADS  via  their  respective  communication 
gateways.  Electronic  mail  traffic  was  passed  between  the  systems.  [Ref.  20:p.  III-3] 


Following  Exercise  Crested  Eagle  84,  the  earlier  Apple  gateways  had  been 
converted  to  new  equipment  for  V  Corps  maneuver  units.  One  SPADS  module,  with  one 
gateway  and  one  staff  duty  station,  was  installed  for  the  1 1ACR  during  Caravan  Guard  V. 
The  11ACR  started  with  one  small  module  to  allow  staff  to  learn  the  system  during  the 
exercise.  They  were  to  have  an  active  role  in  a  highly  dynamic  field  exercise.  Two 
SPADS  modules,  each  with  one  gateway  and  two  staff  duty  stations,  were  installed  for 
SAD.  3AD  had  used  SPADS,  borrowing  equipment  from  V  Corps,  in  two  previous 
exercises,  REFORGER  83  and  Crested  Eagle  84.  [Ref.  21:pp.  V-l  -  V-2] 

The  concept  of  operations  for  Exercise  REFORGER  84  was  for  8ID 
umpires  at  field  locations  to  enter  unit  and  obstacle  locations  into  SPADS  data  bases. 
Umpires  used  the  TACFIRE  Digital  Message  Device  (DMD)  and  single  channel  FM  radios 
to  enter  data  into  the  TACFIRE  computer  at  the  UCC.  This  computer  passed  the  data  to 
SPADS  via  the  hardwire  interface  from  TACFIRE  to  SPADS.  The  UCC  SPADS  module 
then  updated  the  ACC  data  bases  via  the  gateways  at  each  ACC  module.  The  data  were 
used  to  generate  various  reports  and  briefings  using  SPADS  and  SPADS  II  capabilities.  In 
particular,  the  data  were  used  to  automatically  generate  large  screen  displays  of  the  blue  and 
orange  forces  with  DAViD,  using  SPADS  II  workstations.  [Ref.  20:pp.  VI-2  -  VI-8] 

The  objectives  for  this  exercise  were  met  and  exceeded.  When  8ID  was 
tasked  to  provide  exercise  support  for  REFORGER  84,  they  had  no  automated  capability  to 
process  the  data  that  umpires  entered  into  the  TACFIRE  computer  via  the  DMDs  or  to 
display  that  data  for  situation  briefings.  They  did  have  the  SPADS  system  and  had  used 
SPADS  with  varying  degrees  of  success  during  several  exercises.  The  TACFIRE 
interface,  the  obstacle  data  base,  and  the  use  of  DAViD  in  conjunction  with  a  large  screen 
display,  all  integrated  to  work  with  the  SID  SPADS  system,  providing  them  with  the 
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required  capabilities.  This  integration  demonstrated  the  adaptability  and  ingenuity  of  the 
operational  planners  and  users  of  SPADS.  [Ref.  20:p.  VI- 14] 

Fewer  SPADS  problems  occurred  during  Exercise  REFORGER  84  than  in 
previous  exercises  despite  the  integration  of  new  concepts  and  capabilities.  Three  primary 
factors  contributed  to  8ID  having  an  extremely  successful  exercise  [Ref.  20:pp.  VI- 14  -VI- 


1 .  Detailed  planning  began  three  months  prior  to  deployment 

2 .  Adequate  time  was  set  aside  for  training  without  conflicts  from  other  activities 

3.  A  thorough  equipment  check-out  was  conducted  prior  to  leaving  for  the  field 
locations. 

V  Corps  and  its  subordinate  units  had  assigned  each  of  these  three  factors 
varying  degrees  of  importance  throughout  the  three  operational  capability  cycles — this 
inconsistency  resulted  in  widely  divergent  degrees  of  success.  The  highly  successful 
results  of  Exercise  REFORGER  84  proved  the  value  of  giving  each  of  these  factors  a  high 
degree  of  emphasis.  V  Corps  SPADS  users  and  planners  should  have  seen  these  successes 
as  a  further  demonstration  of  the  best  direction  toward  self-sufficiency.  [Ref.  20:p  VI  -15] 
b .  Structure 

DNA  was  particularly  interested  in  the  successful  transition  of  V  Corps  to 
self-sufficiency  before  the  completion  of  the  contract  at  the  end  of  FY  84.  Following  the 
Caravan  Guard  V  IPR,  V  Corps  gradually  started  the  necessary  action  to  establish  a 
dedicated  section  to  plan,  train,  and  support  the  deployment  and  operation  of  SPADS  at  V 
Corps.  [Ref.  1  l:p.  V-3] 

A  decision  briefing  was  presented  to  the  V  Corps  commander  on  21  November 
1983  regarding  the  missions,  goals,  functions,  and  organization  of  the  proposed  Command 
and  Control  Initiatives  Office  (C2IO)  [Ref.  23:pp.  1-10].  All  recommendations  were 
approved.  Requirements  for  officers  to  staff  this  new  organization  were  delivered  to  the 


ACotS,  Gl,  on  1  j>  December  1983.  These  officers  had  already  been  interviewed  by  the 
newly  appointed  C2  Initiatives  Officer  in  late  October  and  early  November  (prior  to  the 
decision  briefing).  Political  infighting  stalled  the  original  assignments  and  certain 
substitutions  had  to  be  accepted  by  the  end  of  December. 

The  C2IO  was  to  have  two  sections — each  consisting  of  four  officers  and  one 
NCO — supervised  by  the  C2  Initiatives  Officer.  The  functions  of  each  section  are 
presented  in  Table  22.  The  C2IO  was  activated  1  January  1984  for  a  period  of  one  year. 
By  1  January  1985,  the  C2IO  was  supposed  to  have  established  a  long-term  program  for 
the  automation  of  the  V  Corps  C  functions,  including  logistical  support  and  sustainment 
training  for  evolutionary  C2  systems.  [Ref.  24:Incl  3] 

The  broad  missions  of  the  C2IO  were  to:  coordinate  all  tactical  C2  initiative 
functions  in  V  Corps,  including  developmental  systems;  SPADS  applications  to  peacetime 
management  information  requirements;  and  C2  developmental  system  sustainment  and 
evolutionary  growth.  The  goals  of  the  C2IO  were  to:  finalize  the  V  Corps  DCP  concept 
and  the  current  technical  baseline  for  SPADS;  install  and  maintain  a  non-secure  SPADS 
system  in  the  peacetime  headquarters  that  could  be  readily  transitioned  to  the  wartime 
configuration;  provide  sustainment  functions,  including  user  training,  staff  assistance  for 
application  development,  and  system  troubleshooting  and  maintenance;  develop  a  V  Corps 
C2  master  plan;  and  identify  the  V  Corps  Management  System  (VCMS)  automation 
requirements  and  prepare  documentation  to  support  acquisition  of  additional  assets.  [Ref. 
2-4  :pp.  1-2] 


TABLE  22 

FUNCTIONS  OF  THE  COMMAND  AND 
CONTROL  INITIATIVES  OFFICE 

PLANS  AND  OPERATIONS  SYSTEMS 

•  Requirements  identification  •  Program  planning 

•  Concept  formulation  •  System  architecture  planning 

•  Exercise  plans  and  operations  •  Configuration  control 

•  Field  evaluation  planning  *  Training  plans  and  coordination 

•  Test  planning  •  User's  documentation 

•  Develop  operational  procedures  •  Property  accountability 


•  Contract  Direction 

•  SPADS  Staff  Training 

•  Data  Base  and  Applications  Development 

•  Coordination  with  Other  Commands: 

-  USAREUR  DCSOPS  C3I 

-  Defense  Nuclear  Agency 

-  Combat  Development  Activity  (CACDA) 

-  Material  Development  Activity  (CECOM) 

-  V  Corps  Major  Subordinate  Commands 
(3 AD,  8ID,  11ACR,  3rd  SUPCOM) 


The  ACofS,  G3,  was  the  proponent  for  the  organization  and  operation  of  the  V 
Corps  command  posts  and  for  the  fielding  of  the  Maneuver  Control  System  (MCS)  within 
V  Corps.  The  C2IO  was  the  proponent  for  the  microcomputer-based  C2  systems  at  the 
different  echelons  of  the  corps  CPs,  and  was  responsible  for  integrating  the  MCS  into  the 
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overall  corps  C2  network.  The  automation  management  officer  (AMO)  was  the  proponent 
for  "Battlefield  Automation  Management";  the  C2IO  was  responsible  for  keeping  the  AMO 
advised  of  tactical  C2  system  planning  and  system  actions.  Finally,  the  C2IO  was  to 
establish  a  program  for  automation  of  the  VCMS  in  coordination  with  the  ACofS,  Resource 
Management.  [Ref.  24:Incl.  3] 

There  had  been  an  absence  of  specific  SPADS  objectives  for  each  exercise 
during  the  first  thirteen  tasks  of  the  SOW.  One  result  of  the  creation  of  the  C2IO  was  the 
development  of  specific,  measurable  SPADS  objectives  for  each  exercise  that  occurred 
during  th  1_.  t  ten  tasks.  [Ref.  20:p.  3] 

The  software  accomplishments  that  occurred  during  the  last  ten  tasks  were  the 
result  of  a  concerted  effort  by  the  C2IO  to  implement  only  those  refinements  and 
enhancements  that  met  mission-essential  C2  functions.  The  significant  software 
modifications  during  this  period  were  in  response  to  requirements — identified  by  the  C2IO 
during  Exercise  Crested  Eagle  84 — for  the  communications  gateway  software  and  the 
decision  graphics  package.  [Ref.  20:pp.  7-8] 

The  SPADS  objectives  for  Exercise  Crested  Eagle  were  to  install  the  new 
gateway  in  all  DCP  modules  as  well  as  evaluate  the  new  videodisc  and  VBDS  software. 
C2IO  members  aggressively  tested  and  validated  the  software  and  made  a  concerted  effort 
to  identify  shortfalls,  refinements,  and  enhancements  for  SPADS.  C2IO  officers  mandated 
21  modifications  to  the  SPADS  software  for  OC3.  These  modifications  involved  the  EMS, 
text  editor,  DBMS,  VBDS,  CAM  and  NCP  software.  [Ref.  20:p.  8] 

Lack  of  a  comprehensive  training  management  program  in  the  past  had  caused 
operational  problems  during  nearly  every  exercise.  In  addition,  because  corps  staff  users 
and  decision  makers  never  recognized  the  power  and  potential  of  SPADS,  the  system  had 
not  been  integrated  into  the  corps  C2  processes.  Staff  officers  and  NCOs  who  were 


performing  C2  functions  were  not  aware  of  SPADS  capabilities,  while  previously  trained 
operators  and  system  managers  were  not  involved  in  C2  functions.  And  neither  the  data 
bases  nor  their  uses  had  been  refined  from  OC1  through  the  close  of  OC3.  These  factors 
had  all  adversely  affected  V  Corps  staff  user  attitudes  and  the  integration  of  SPADS  C2 
functions.  [Ref.  20:p.  10] 

This  counterproductive  situation  improved  sharply  when  the  C2IO  began  a 
systematic  training  program  which  was  managed,  planned,  and  conducted  by  V  Corps 
personnel.  This  program  supported  only  the  V  Corps  exercise  objectives  identified  by  the 
C2IO.  Training  was  scheduled  well  in  advance  of  exercises.  The  number  of  trainees  from 
each  staff  section  was  based  on  the  needs  of  the  command  posts.  Periodic  refresher 
training  was  mandated  for  all  personnel.  Finally,  follow-up  training  was  scheduled  after 


exercises. 


Parallel  to  the  improvement  in  training  was  a  concerted  C2IO  effort  to  improve 
the  SPADS  documentation.  The  documentation  included  several  versions  of  the  Operator's 
Manual,  a  System  Manager's  Manual,  and  a  Staff  Officer's  Manual.  These  manuals  varied 
greatly  in  quality,  ranging  from  the  slickly  produced  Staff  Officer's  Manual  to  the  wholly 
inadequate  System  Manager's  Manual.  The  Operator's  Manual,  for  example,  contained 
out-of-date  instructions  for  each  of  the  SPADS  capabilities  as  well  as  obsolete  descriptions 
of  the  hardware,  software  and  system. 

The  System  Manager's  Manual  was  outdated  as  soon  as  the  Corvus-based 
gateway  superceded  the  Apple  n+  CGS.  The  C2IO  produced  a  timely  and  concise  version 
of  the  System  Manager's  Manual  before  Exercise  Crested  Eagle.  Changes  updating  the 
Operator's  Manual  were  ready  in  advance  of  Exercise  Caravan  Guard  V  in  May  1984. 
Almost  up-to-date  versions  of  both  manuals  were  finally  delivered  by  the  developer  at  the 
end  of  OC3.  [Ref.  20:pp.  11-12] 


The  developer  delivered  six  of  the  iast  21  software  modifications  shortly  before 
Exercise  Caravan  Guard  V.  The  C2IO  received  a  short,  but  intense,  familiarization  session 
on  these  changes,  prepared  updated  training  materials,  and  conducted  training  for  V  Corps 
personnel.  The  Caravan  Guard  V  IPR  noted  that  "Fewer  SPADS  problems  occurred 
during  this  exercise  than  in  any  previous  exercise."  [Ref.  20:p.  12] 

The  next  major  step  V  Corps  took  was  to  distribute  the  V  Corps  Dispersed 

Command  Post  LOI  in  1985.  This  document  provided  instructions  for  the  DCP 

configuration,  listed  module  and  staff  section  responsibilities,  established  authorized 

equipment  levels,  and  dictated  that  SPADS  was  to  be  used  as  the  V  Corps  C2  system  for  all 

exercises.  The  LOI  presented  an  honest  appraisal  of  the  employment  constraints  of  and  the 

threats  to  the  V  Corps  DCP.  It  specifically  waived  the  requirement  for  a  ten-kilometer 

dispersal  between  main  CP  modules  [Ref.  5:p.  2]: 

With  the  current  V  Corps  communications  equipment  and  assets  the  modules  of  the 
main  CP  can  not  [sic]  be  dispersed  further  than  1200  feet  from  the  Signal  Center. 

It  further  stated  that  this  critical  survivability  requirement  would  not  be  met  until 
some  unspecified  future  time  [Ref.  5:p.  2]: 

...die  concept  of  a  modularized,  dispersed  command  post  which  cannot  be  dispersed 
until  the  introduction  of  Mobile  Subscriber  Equipment  (MSE)  communications 
network.  This  system  will  give  each  module  its  own  signal  center  and  allow  true 
dispersed  operations. 

Figure  5.7  displays  the  V  Corps  DCP  constrained  by  communications  equipment 
in  the  mid-1980s.  It  also  presents  the  SPADS  staff  duty  station  and  gateway  assignments 
for  the  six  modules  that  made  up  the  V  Corps  DCP.  Figure  5.8  shows  the  planned  V 
Corps  DCP  employment  after  the  corps  received  the  new  Mobile  Subscriber  Equipment. 
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Figure  5.8.  V  Corps  DCP  Employment  (Mobile  Suscriber  Equipment) 


D  .  DATA  GENERATION 


The  data  generated  for  the  five  exercises  of  OC3  are  shown  in  Table  236.  The  data 
generation  worksheet  and  formulas  discussed  in  Chapter  II  were  used  to  produce  values  for 
this  OC.  The  means  for  each  evaluation  category  are  displayed  in  Figure  5.9. 

As  an  aid  to  better  understanding  of  SPADS  and  the  V  Corps  DCP  employment,  three 
additional  evaluations  were  conducted  after  OC3.  The  first  was  an  evaluation  of  Wintex 
85;  during  this  exercise  TCATA  conducted  the  last  formal  evaluation  of  SPADS.  The  next 
two  evaluations  were  scenarios  based  upon  the  V  Corps  DCP  LOI.  The  second  evaluation 
was  conducted  with  the  dispersal  constrained  by  the  communications.  The  final  evaluation 
was  conducted  with  full  MSE  support  of  the  V  Corps  DCP.  The  data  generated  for  these 
three  evaluations  are  shown  in  Table  247  .  The  means  for  each  evaluation  category  are 
displayed  in  Figure  5.10. 

A  brief  review  of  the  data  generation  procedures  from  Chapter  II  are  presented  in  this 
paragraph.  After  action  and  lessons  learned  reports  were  collected  from  V  Corps,  DNA, 
and  the  developer  for  each  exercise  during  this  final  operational  capability  cycle.  The  V 
Corps  DCP  LOI  was  the  source  of  data  for  the  two  scenarios.  Values  were  determined  for 
every  measure  from  each  exercise  using  the  worksheet,  definitions,  and  procedures 
specified  in  Chapter  EL  The  measures  were  individually  considered  as  binary  conditions 
for  each  DCP  module  that  participated  in  the  exercise  or  scenario  under  consideration.  The 
summed  measures  (e.g.,  FAIR,  XMOTi,  and  XCSTi)  received  their  cumulative, 
unweighted  scores  based  upon  their  constituent  measures  of  performance  or  effectivemess. 
The  final  measure,  C2/FE,  was  calculated  in  accordance  with  the  procedure  specified  in 
Chapter  II.  The  results  for  each  exercise  are  displayed  in  Table  23,  and  the 


6  The  following  sources  provided  raw  data  for  the  final  three  evaluations:  Ref.  22 
(Wintex  85)  and  Ref.  6  (V  Corps  DCP  LOI-based  scenarios). 
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Figure  5.9. 


means  for  each  evaluation  during  OC3  are  shown  in  Figure  5.9.  The  results  for  the  Final 
three  evaluations  are  presented  in  Table  24,  and  the  means  for  these  evaluations  are  shown 


in  Figure  5.10. 

E.  AGGREGATION  AND  INTERPRETATION  OF  MEASURES 

Once  again.  After  Action  and  Lessons  Learned  Repons  contained  a  great  deal  of  data 
and  were  extremely  helpful  in  understanding  the  characteristics  of  the  experiments  during 
the  exercises. 

1 .  C2  Mission  Orientation 

The  value  of  C2  Mission  Onentation,  XMOTi,  begins  at  approximately  the 
same  level  as  OC2,  rises  slightly  and  then  gradually  recedes  until  the  end  of  OC3.  There 
was  a  measurable  loss  in  effectiveness  by  the  end  of  the  experiment  period.  The  following 
three  sections  interpret  the  three  components  of  C2  Mission  Orientation. 

a .  C2  Process 

There  was  a  sharp  loss  in  functionality  during  OC3  from  the  Caravan  Guard 
V  to  the  end  of  the  experiment.  While  the  functions  of  the  V  Corps  commander  and  staff 
may  have  remained  constant,  the  DCP  environment  and  SPADS,  in  particular,  caused  a 
gradual  decrease  in  the  commander's  and  staffs  abilities  to  exercise  command  and  control 
of  the  corps.  The  flat  response  during  the  three  additional  observations  may  represent  the 
C2  process  steady  state  in  a  resource-constrained  environment. 

b.  Physical  Entities 

Physical  entities  continued  to  change  during  OC3.  Some  new  software  was 
introduced,  and  refinements  were  continually  made  to  established  software  functions.  The 
new  communications  gateway  package  was  integrated  into  the  DCP  environment.  The 
value  of  capacity  reached  a  three -year  high  during  Exercise  Caravan  Guard  V.  With  the 
fielding  of  the  upgraded  CGS  throughout  the  V  Corps  DCP,  the  system's  capacity  reached 


a  new  level.  The  last  two  evaluations  sustained  the  same  level  of  capacity  as  Exercise 
Caravan  Guard  V. 


c.  Structural  Components 

The  value  of  the  structural  measure  modulates  gradually  throughout  OC3. 
SPADS  was  able  to  consistently  accomplish  the  transmission  of  critical  information 
required  by  the  commander  .  Although  more  traffic  was  generated  during  each  exercise, 
SPADS  was  able  to  consistently  provide  the  V  Corps  commander  with  dependable,  critical, 
decision  making  information.  Theoretically,  the  values  of  timeliness  reached  a  higher  state 


during  the  last  two  evaluations  than  during  the  previous  three  operational  capability  cycles. 
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SPADS  made  more  progress  towards  consistently  achieving  command 
survivability  during  OC3.  Except  for  the  first  two  command  post  exercises,  dispersion 
between  modules  gradually  increased  and  more  modules  were  added  to  the  corps  system. 
The  low  value  for  the  next-to-last  evaluation  reflects  an  honest  appraisal  of  the 
communications-constrained  environment.  Conversely,  the  final  measure  represents  the 
highest  possible  value  possible  using  MSE.  Defying  the  trends  from  OC1  and  OC2, 
significant  progress  was  made  toward  redundancy;  this  can  be  specifically  related  to  new 
command  influence  and  staff  orientation.  The  values  in  the  final  two  evaluations  represent 
an  ideal  redundant  environment.  Finally,  the  values  of  reliability  and  transportability  rise 
slowly  to  the  high  points  of  Crested  Eagle  84  and  Caravan  Guard  V.  Like  redundancy,  the 
last  two  values  represent  an  ideal  state  for  continuity  of  operations. 


SPADS  did  evolve  during  OC3  based  upon  the  operational  lessons  learned.  The 
evolution  involved  hardware,  software,  protocols,  and  communications  interfaces. 
SPADS  reaches  new  high  values  for  C2/FE  and  only  gradually  declined  when  it  entered  a 


highly  constrained,  resource-depleted  environment  after  all  sponsors  stopped  funding  at  the 
end  of  OC3.  SPADS  was  becoming  institutionalized  within  the  V  Corps  C2  structure; 
unfortunately,  the  creation  of  the  C2IO  and  the  distribution  of  the  DCP  LOI  occurred  in  a 
period  when  no  sustaining  resources  were  available.  The  potential  values  of  C2/FE  rise 
distinctly  when  V  Corps  was  forced  to  take  maximum  advantage  from  their  automated  C2 
system.  The  value  of  C2/FE  could  nearly  double  in  value,  compared  to  the  start  of  OC3,  if 
the  V  Corps  DCP  is  employed  in  an  MSE-supported  environment.  . 

Figure  5.11  provides  the  cumulative  (unweighted)  value  of  each  evaluation 
category  for  each  exercise  of  OC3.  Figure  5.12  provides  the  cumulative  (unweighted) 
value  of  each  evaluation  category  for  each  evaluation  conducted  after  the  operational 
capability.  Figure  5.13  displays  the  values  of  each  measure — XMOTi,  XCSTi,  C2/FE — 
throughout  each  exercise  of  the  Final  operational  capability.  Figure  5.14  displays  the  values 
of  each  measure — XMOTi,  XCSTi,  C2/FE — for  each  evaluation  conducted  after  OC3. 

F.  SUMMARY 

This  final  section  frankly  discusses  the  procedures,  training,  communications, 
hardware,  and  software  as  they  relate  to  the  V  Corps  DCP  experiment  throughout  OC3.  In 
addition,  the  conclusions  of  the  TCATA  evaluation,  from  Wintex  85,  will  be  included 
where  appropriate. 

I .  Erocetiur.es 

Command  emphasis  of  the  V  Corps  C2  system  was  a  reliable  predictor  of  the 
satisfactory  performance  of,  or  delay  in  effective  performance  by,  staff  users  during  tests 
and  exercises  [Ref.  ll:pp.  21-22J.  Generally,  if  the  commander  emphasizes  the 
experimental  C2  system  concept,  user  personnel  respond  accordingly  [Ref.  8:p.  65-66], 
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Evaluations  of  the  Three  Problems  for  OC3 


Evaluations 


Comparisons  of  the  Three  Measures  for  OC3 


Figure  5.14.  Comparisons  of  the  Three  Measures  Across  Three  Scenarios 
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It  was  absolutely  essential  that  thoughtful  planning  and  procedures  were 
documented.  V  Corps  needed  to  document  its  objectives  and  operational  procedures  by 
constructing  well-defined  standing  operating  procedures  (SOP).  These  SOPs  should  have 
reflected  the  evolutionary  development  of  the  V  Corps  DCP  as  it  changed  with  new 
operating  procedures,  new  goals  and  objectives,  and  system  enhancements  that  followed 
hardware  and  software  upgrades.  The  SOPs  should  have  provided  the  following 
information  for  new  personnel: 

1 .  Operating  procedures 

2 .  Schematics  and  loading  plans 

3 .  Hardware  operation  and  maintenance 

4.  Training  procedures 

5 .  Documentation  requirements 

Additions  to  the  SOP  needed  to  be  systematically  and  faithfully  updated  if  they 
were  to  serve  their  useful  purposes  as  C2  mechanisms.  Once  again,  this  activity  requires 
command  emphasis  and  staff  interest.  [Ref.  8:pp.  65-66] 

Lack  of  identification  of  information  needed  for  the  development  of  well-constructed  SOPs 
was  a  crucial  failure  during  the  DCP  program  development.  Such  a  commitment  was 
necessary  to  ensure  that  personnel  knew  their  duties;  that  the  C2  system  was  maintained, 
set  up,  and  operated  properly;  and  that  the  organizations  were  in  a  position  to  identify  new 
needs  and  applications  for  system  evolution.  There  should  have  been  a  principal  SPADS 
staff  officer  who  had  the  backing  of  the  commander  and  staff  from  the  beginning  of  the 
DCP  experiment.  This  individual  should  have  been  involved  in  the  initial  SOP 
development  to  provide  the  direction  that  guided  systems  integration  throughout  the  staff 
elements  and  group  functions.  This  principal  staff  officer  should  have  assessed  the  manner 
in  which  system  capabilities  would  assist  in  the  performance  of  the  staffs  C2  functions. 
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Following  exercises  and  tests,  the  usefulness  of  the  system,  its  operability,  and  the 
identification  of  new  capabilities  should  have  been  evaluated  and  incorporated  into  the 
SOP.  Likewise,  the  failure  to  involve  appropriate  personnel  in  identifying  communication, 
hardware,  and  software  as  well  as  training  requirements  created  problems  until  the  creation 
of  the  C2IO.  [Ref.  8:pp.  66,  69] 

2.  Training 

Sufficient  operators  and  system  managers  were  seldom  available  for  all  modules, 
particularly  during  field  exercises  when  24-hour  operations  exacerbated  the  requirement  for 
continuous  operations.  Operators  required  hands-on  practice  on  equipment  between 
exercises;  unfortunately,  only  the  C2IO  had  the  resources  to  maintain  an  entire,  functional 
module  during  garrison  operations.  Well-trained  SPADS  operators  and  staff  officers 
would  have  provided  the  maximum  value  to  the  V  Corps  C2  process  if  their  duties  had 
been  integrated  with  SPADS  capabilities. 

The  importance  of  training  throughout  the  DCP  experiment  was  profound. 
Those  few  personnel  who  were  previously  trained  and/or  had  prior  field  experience  gained 
the  confidence  and  the  skill  necessary  to  experiment  with  applications  which  substantially 
improved  the  battlefield  view  available  to  the  commander  and  staff.  A  systematic  training 
program  was  necessary  to  provide  sufficient  numbers  of  properly- trained  operators  and 
system  managers  for  24-hour  operations  in  all  modules  of  the  V  Corps  DCP.  [Ref.  8:pp. 
69-70] 

3 .  Communications 

The  communication  of  accurate  and  timely  battlefield  information  should  have 
been  the  core  of  an  effective,  distributed  C2  system  whose  twofold  objectives  consisted  of 
sustained  decision  support  and  rapid  information  exchange  capabilities  throughout  all  DCP 
operations  [Ref.  8:p.  71].  The  fact  that  the  C2IO  was  composed  primarily  of 


communicators  was  met  with  some  derision  in  January  1984.  However,  until  operationally 
oriented  communicators  experienced  SPADS  from  the  inside,  the  C-E  staff  and  Signal 
Brigade  did  not  provide  the  consistent  multichannel  support  required  to  make  SPADS  work 
at  different  locations  and  echelons.  The  C2IO's  experienced  communications  planners 
were  needed  to  make  provisions  for  the  staff  to  distribute  information  horizontally 
throughout  the  dispersed  corps  CPs  and  vertically  from  CENTAG  down  to  the  maneuver 
commanders.  [Ref.  8:p.  75] 

4 .  Hardware 

As  previously  indicated,  definition  of  requirements  and  identification  of 
operational  specifications  were  important  considerations  lacking  in  the  SPADS  system 
design.  The  lack  of  operational  user  involvement  in  the  design  of  power  systems, 
grounding  protection,  and  the  local  area  network  caused  critical  failures  during  the  8ID 
SPADS  program.  Equally  important,  if  not  more  critical,  was  hardware  selection, 
modification,  integration,  and  planned  future  innovations  based  upon  testing  and  field 
exercise  findings.  There  was  a  need  for  a  concerted  effort  between  the  designer/engineer 
team  and  military  users  to  ensure  that  hardware  met  military  specifications  in  the  field 
environment.  Throughout  the  DCP  experiment,  the  critical  hardware  components  were 
packaged  in  rugged  containers  that  nearly  always  protected  them  no  matter  what  level  of 
abuse  they  experienced;  however,  those  "nice-to-have"  items,  e.g.,  graphics  tablets  and 
joysticks,  were  not  made  for,  were  not  protected  against,  and  could  not  withstand  the 
users'  operational  environments.  [Ref.  8:pp.  81-82] 

This  thesis  has  presented  hardware  issues  that  should  be  addressed  when 
implementing  and  fielding  an  automated  C2  system  — based  upon  NDI  acquisitions — in  a 
DCP  environment.  The  problems  concerning  power,  grounding,  interoperability,  and 
usability  could  have  been  solved  sooner  if  the  operational  users  had  been  involved  in  the 
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design  process  from  the  beginning.  Certain  hardware  problems  may  appear  simple  enough 
to  avoid,  suggesting  that  they  need  not  have  been  mentioned.  The  experience  gained  from 
evaluating  the  SPADS  system,  however,  indicates  otherwise.  The  most  fundamental 
mistakes  occurred  due  to  the  human  errors  that  resulted  from  basic  design  oversights. 
These  numerous  mistakes  impeded  the  successful  fielding  and  attainment  of  exercise 
objectives.  SOPs  and  specifications,  revision  of  documentation  as  technology  and 
requirements  changed,  involvement  of  the  operational  user  in  the  system  design  phase,  and 
adequate  time  for  preparation  and  planning  are  necessary  for  effective  hardware  integration. 
rR*“f.  8:p.  761 

5 .  Software 

Of  all  the  C2  system  components,  the  SPADS  system  software  provides  the  best 
example  of  an  element  that  must  be  tested  by  the  operational  user  in  evolutionary 
development  cycles.  Testing  was  essential  if  the  software  was  to  meet  operational 
requirements,  adequately  automate  staff  procedures  and  functions,  integrate  successfully 
with  existing  hardware  and  with  future  upgrades,  and  respond  to  user  requirements 
through  hands-on,  gamson-to-field  operations.  More  than  any  other  system  component, 
the  software  evolved  best  after  it  was  refined  through  exercise  and  field  test.  Conversely, 
software  requirements,  SOP  documentation,  and  the  identification  of  data  structures  were 
more  difficult  for  the  operational  user  to  construct  alone.  Here  the  developer  performed  a 
poor  service  for  the  military  user;  instead  of  engaging  in  an  intensive  user-developer 
dialogue  to  get  needed  information,  the  developer  simply  selected  and  implemented  his  own 
doctrinal  concepts.  The  rationale  for  having  a  software  developer  on-site — to  furnish 
additional  software  support  prior,  during,  and  following  exercises — was  a  sham;  the  local 
developer's  representative  was  not  allowed  to  make  the  required  modifications  on-site. 
Such  changes  were  only  authorized  at  the  parent  organization.  [Ref.  8:p.  84] 


The  final  section  of  this  chapter  regards  the  TCATA  evaluation  of  SPADS  during 
Wintex  85  [Ref.  22].  This  evaluation  was  particularly  appropriate  to  this  thesis  because  it 
offered  an  outsider's  perspective  of  what  was  happening  in  the  V  Corps  DCP.  The  focus 
of  that  evaluation  was  germane  to  this  research  because  it  provided  reinforcing  and 
complementary  data  collected  immediately  after  the  third  operational  capability  concluded. 

The  TCATA  evaluation  measured  two  general  areas  to  determine  whether  the  V 
Corps  C2  system  assisted  the  commander  and  staff:  (1)  did  the  overall  V  Corps  C2  system 
assist  the  commander  and  staff:  and  (2)  what  assistance  was  provided  by  SPADS  to  the  V 
Corps  C2  functions,  and  what  were  the  key  characteristics  [Ref.  22:pp.  11-49]?  Each  of 
these  questions  were  addressed  by  sub-issues  discussed  below. 

The  two  sub- issues  to  the  first  question  were:  (1)  does  the  C2  system  permit  the 
commander  and  staff  to  monitor  and  be  knowledgeable  of  the  current  tactical  situation,  and 
(2)  are  the  V  Corps  communications  adequate  to  support  the  C  system?  [Ref.  22:pp  1 1- 
37], 

TCATA  found  that  the  V  Corps  staff  "...consistently  demonstrated  the  inability 
to  monitor  the  overall  tactical  situation..."  at  all  six  modules.  It  also  found  that  "...the 
staff,  in  general,  was  able  to  monitor  the  location  data  better  when  using  SPADS."  [Ref. 
22:pp.  11-13]  Further,  it  stated  that  equipment  and  personnel  shortages  in  the  V  Corps 
Signal  Brigade  degraded  its  ability  to  perform  its  wartime  mission  [Ref.  22:pp.  13-21], 

The  TCATA  evaluation  presented  the  following  recommendations  that  are 

directly  related  to  the  subject  of  this  thesis  [Ref.  22:p.  37]: 

Develop  a  standing  operating  procedure  (SOP)  that  clearly  establishes  procedures  for 
information  flow  (including  SPADS)  both  within  and  between  modules  and  echelons. 

Conduct  section  oriented  staff  training  on  staff  procedures  within  the  CP.... 


Expedite  fielding  of  mobile  subscriber  equipment;  current  C2  communications  requires 
bulky  equipment  and  is  cable  intensive.... 

The  second  area  was  divided  into  seven  sub-issues,  each  of  which  are  presented 
and  discussed  sequentially  in  the  succeeding  paragraphs  [Ref  22:pp.  38-49]: 

(1)  What  was  the  effect  of  SPADS  on  staff  functions,  organization,  workload 
and  procedures?  TCATA's  assessment  was  [Ref.  22:pp.  38-39]: 

...There  was  a  shortage  of  SPADS  trained  personnel. 

The  corps  staff  needed  additional  training  on  staff  procedures. 

SPADS  was  an  asset  since  it  improved  C2  by  providing  the  capability  for  word 
processing  and  hard-copy  message  traffic.  But  the  system  is  difficult  to  learn  and 
needs  more  efficient  software. 

(2)  What  were  commander  and  staff  perceptions  of  the  system's  products  to 
support  C2  functions?  TCATA  stated  that  the  individual  products  were  not  rated  separately 
from  the  system.  This  seems  a  glaring  error  on  the  part  of  the  evaluation  team.  The  sub¬ 
issue  suggests  that  this  should  have  been  done;  the  evaluators  spent  10  hours  per  day 
collecting  data  about  such  inconsequential  matters  as  the  number  of  times  an  operator 
logged  onto  the  system.  A  rating  scheme  for  the  diverse  information  exchange  and 
decision  support  capabilities  would  have  permitted  V  Corps  to  invest  its  meager  resources 
in  the  most  valuable  areas  without  expending  resources  of  the  entire  system. 

(3)  What  were  the  interoperability  and  interface  capabilities  of  systems  in 
support  of  the  C2  system?  There  were  no  systems  other  than  SPADS  supporting  the  C2 
system. 

(4)  What  was  the  system's  effect  on  operator  workload  and  productivity?  The 

TCATA  assessment  stated  [Ref.  22:pp.  39-45]: 

Generally,  the  operators  appeared  to  support  SPADS  and  consider  it  an  aid  to  getting 
their  job  done.  However,  it  is  felt  that  the  system  needs  improvement,  particularly  in 
speed,  reliability  and  simplicity  of  operation. 


(5)  How  effective  were  the  training  and  orientation  programs  in  providing  for 
the  integration  and  the  use  of  the  system  in  the  organization?  TCATA  correctly  observed 
[Ref.  22:pp.  39-45]: 

The  corps  does  have  a  multiechelon  training  program  for  SPADS.  However,  there 
appeared  to  be  too  little  command  emphasis  on  training  which  resulted  in  problems 
such  as  poor  attendance  and  people  starting  a  class  without  finishing  it.  There  was  a 
high  personnel  turnover  which  also  reduced  the  level  of  proficiency  of  the  average 
operator.  In  addition,  the  user  manual  is  too  complex  for  most  operators. 

(6)  What  is  the  in-garrison  application  of  SPADS  and  how  is  training 

proficiency  maintained?  TCATA  reported  [Ref.  22:pp.  45-46]: 

The  in  c arrison  applications  of  SPADS  are  minimal  and  consist  mostly  of  infrequent 
use  as  a  stand-alone  device.  Review  training  for  system  managers  and  operators  is 
scheduled  quarterly;  how-ever,  the  selection  process  for  attendees  is  vague. 

(7)  What  is  the  test  availability  of  the  C2  system?  TCATA  reported  that  the 
equipment  was  very  dependable.  They  found  that  SPADS  was  available  between  95  and 
98  percent.  [Ref.  22:pp.  46-48] 

TCATA’s  overall  assessment  of  the  issue  of  whether  or  not  SPADS  provided 

assistance  to  the  V  Corps  C2  system  was  that  [Ref.  22:pp.  48-49]: 

The  assistance  provided  by  SPADS  marginally  improved  the  general  capabilities  of  the 
commander  and  his  staff  to  perform  C2  functions  during  the  CPX. 

In  the  "Executive  Summary"  to  the  evaluation,  TCATA  summarized  the 
following  observations  about  SPADS  and  the  V  Corps  DCP  [Ref.  22:unnumbered  4th 

page]: 

•  SPADS  was  used  to  improve  command  and  control  by  providing  the  capability  for 
word  processing  and  exchange  of  hard  copy  message  traffic. 

•  SPADS  was  rated  an  asset  by  the  staff. 

•  SPADS  equipment  was  operadonal  95  percent  of  the  rime. 

•  There  was  very'  limited  in-garrison  use  of  the  system. 

•  Of  27  operators,  19  stated  they  had  received  no  formal  training. 


•  There  was  a  shortage  of  people  in  the  plans  and  intelligence  modules,  and  the  plans 

and  rear  modules  lacked  the  correct  rank  structure  and  skill  levels. 

•  The  system  is  difficult  to  learn  and  needs  more  efficient  software. 

•  Erroneous  data  base  entries  occur  because  there  are  no  mandatory'  or  legal  entries 
required  for  unit  identification. 

•  The  Battlefield  Information  Reporting  System  output  cannot  be  used  as  received  to 
readily  determine  the  task  organization  and  status  of  a  unit. 

•  Due  to  data  base  contamination  existing  at  the  start  of  the  exercise,  SPADS  did  not 
provide  a  common  perception  of  the  battlefield. 

7 .  Outlook 

SPADS  was  an  evolutionary  development  with  each  phase  based  upon  the 
results  of  lessons  learned  during  field  exercises.  In  spite  of  the  problems  that  naturally  and 
inevitably  occurred  during  a  rapid  fielding,  SPADS’  development  clearly  showed  that  the 
evolutionary  development  process  was  a  viable  method  to  rapidly  field  an  effective  C2 
system.  The  benefits  associated  with  this  process  were  significantly  quicker  fielding  and 
implementation,  elimination  of  obsolescence,  lower  costs,  end-user  operation,  and 
increased  survivability. 

The  summaries  of  chapters  III,  rv  and  V  presented  a  critical  analysis  of  the  state 
of  procedures,  training,  communications,  hardware,  and  software  throughout  the  V  Corps 
DCP  experiment.  Chapter  VI  will  discuss  recommendations  and  conclusions  for  SPADS, 
evolutionary  development,  and  the  Modular  Command  and  Control  Evaluation  Structure. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 

Based  on  operational  experience  with  SPADS  at  V  Corps  from  1984  through 
1986,  the  author  stated  three  problems,  in  Chapter  I,  that  he  would  answer  to  evaluate  the 
effectiveness  of  SPADS.  The  MCES  provided  the  methodological  framework  to  define, 
bound,  and  analyze  SPADS  and  its  evolving  relationship  with  the  V  Corps  DCP  concept. 
Appropriate  measures  of  performance,  effectiveness,  and  force  effectiveness  were 
specified,  through  MCES,  to  answer  these  problems.  The  following  sections  are  the 
author's  own  findings  and  opinions,  except  where  otherwise  noted. 


A.  SPADS  PROGRAM  CONCLUSIONS 

SPADS  evolved  because  of  the  following  seven  design  mandates  [Ref.  7:pp.  16-17]: 

1 .  Provide  an  information  exchange  capability  which  would  enable  widely  dispersed 
command  post  elements  to  maintain  a  common  perception  of  the  battlefield  situation 
and  thus  effectively  direct  the  employment  of  friendly  forces 

2 .  Provide  automation  of  map  displays  for  C2  support;  minimize  the  time  required  to 
collect,  process,  analyze,  store,  retrieve,  and  display  map  information 

3 .  Minimize  data  transmission  requirements  so  the  system  can  use  available  U.S.  Army 
communications  systems 

4.  Provide  for  survivability  through  a  dispersed  system  that  supports  continuity  of 
operations  and  rapid  relocations 

5 .  Provide  computational  support  to  each  command  post  element 

6.  Develop  a  user-friendly  system  (one  that  is  easily  learned  and  understood,  and  easy 
to  operate) 

7.  Provide  a  sufficiently  rugged,  low-cost  system  which  will  operate  in  a  field 
environment  and  support  field  tests 

These  seven  mandates  were  applied  throughout  each  operational  capability.  Their 
influences  were  examined  in  Chapters  III,  IV,  and  V.  These  design  principles  can  be 
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mapped  to  the  SPADS  statement  of  work  tasks.  They  can  be  further  mapped  through  OC 


requirements  to  st  mific  implementations  at  the  staff  duty  station,  module  and  network 


levels.  The  following  sections  examine  the  application  of  each  mandate,  and  discuss 


specific  pros  and  cons  of  its  implementation. 


1 .  Maintain  a  Common  Battlefield  Perception. 


Every  module  of  the  dispersed  command  post  had  to  share  a  common  perception 


of  the  battlefield  situation  if  operations  were  to  be  effectively  planned,  executed,  and 


controlled.  This  meant  that  every  module  had  to  share  the  same  information.  A  key  design 
concept  '  SPADS  was  the  replication  of  the  essential  pans  of  the  Current  Situation 


information  available  at  every  module.  In  theory,  designated  staff  sections  in  each  module 


were  responsible  for  maintaining  a  portion  of  the  Current  Situation  data  base  and  for 


transmitting  updates  to  all  other  modules.  This  common  perception  design  concept: 


1 .  Allowed  the  commander  and  staff  immediate  access  to  critical  data  on  the  total 
situation  at  any  module 


2.  Provided  a  common  perception  of  all  aspects  of  unit  status  to  all  headquarters 
modules 


3 .  Provided  the  redundancy  necessary  for  continuity  of  operations 


4.  Depended  less  on  communications  than  remote  query  to  a  central  data  base 


5 .  Relieved  the  staff  from  requesting  information  from  distant  modules,  or  from  being 
queried  by  distant  staff  sections 


6.  Depended  upon  the  following  SPADS  capabilities:  DBMS  (BIRS  and  OB),  VBDS, 
Briefing,  and — ultimately — Current  Situation 


a.  Pros: 


The  Current  Situation  software  worked.  It  was  graphics-oriented  and  could 
clearly  exhibit  "exception  data”  at  all  modules.  This  was  one  of  the  first  successfully 


completed  software  sub-modules  of  SPADS. 
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The  Data  Base  Management  System  (DBMS)  evolved  into  a  powerful 
reports  generator  that  delivered  force  structure  information  to  all  staff  users.  DBMS  was 
consistent,  accurate  and  timely.  Its  interface  with  the  Video  Battlefield  Display  System 
(VBDS)  had  the  same  characteristics.  Both  the  DBMS  and  VBDS  were  able  to  provide  the 
commander  and  the  staff  with  a  timely  and  accurate,  common  perception  of  the  battlefield  at 
any  module. 

b.  Cons: 

The  entire  Current  Situation  process  was  manual.  Procedures  were  lengthy, 
complicated,  and  tiresome.  Thr  stem  was  unpredictable  to  novice  users  and  did  not 
tolerate  mistakes.  Only  an  educated  staff  officer  who  had  used  the  Current  Situation  data 
base  software  before  could  successfully  enter  the  correct  data  in  a  timely  manner.  In  fact, 
the  entire  process  was  so  complicated  that  a  contractor  representative  was  usually  required 
to  enter  the  staff  section's  work.  By  1985,  Current  Situation  had  devolved  into  an 
"undocumented"  feature  of  SPADS. 

The  DBMS  evolved  under  duress.  As  a  file  management  system  originally 
developed  by  the  contractor  merely  to  satisfy  the  SOW,  the  program  did  not  begin  to  meet 
the  needs  of  the  commander  and  staff.  By  1984,  the  Battlefield  Information  Reporting 
System  (BIRS)  portion  of  the  DBMS  had  progressed  to  the  point  where  it  could  meet  most 
needs  of  the  G3  Operations  and  Plans  sections.  However,  BIRS  still  did  not  meet  the 
needs  of  most  other  staff  sections.  Furthermore,  the  Order  of  Battle  (OB)  data  base  was 
static  after  initial  development,  and  frequently  was  not  used  by  any  staff  other  than  the  G2. 

2  .  Automate  Map  Graphics. 

A  key  SPADS  objective  was  to  minimize  the  "culture  shock"  associated  with  the 
introduction  of  new  equipment  and  procedures.  The  videodisc  technology  employed  in 
SPADS  stored  over  50,000  color  photographs  of  standard  military  maps  from  the  Western 


European  theater.  Map  images  were  overlayed  with  standard  military  symbols  and 
displayed  on  an  analog  color  monitor.  This  method  avoided  computer-generated  maps  that 
didn't  have  a  one-to-one  correspondence  with  the  standard  tactical  maps  in  the  command 


posts. 


a.  Pros: 


Everyone  used  the  same  maps,  but  could  view  them  at  the  scale  most 
appropriate  to  his/her  tasks.  Various  combinations  of  friendly  and  enemy  units  could  be 
displayed.  All  current  force  information  in  the  data  bases  could  be  displayed 
simultaneously  or  be  selected  by  echelons.  Simple  key  board  commands,  help  menus  and 
easy  operation  made  the  VBDS  one  of  the  few  software  functions  that  could  be  mastered  by 
any  soldier. 

b.  Cons: 

Although  unit  location  information  could  be  reliably  displayed  in  a  timely 
manner,  no  other  standard  military  markings  could  be  displayed  easily.  Various 
experiments  with  paddles,  joysticks,  and  graphic  tablets  failed  to  provide  a  simple 
capability  to  draw  appropriate  force  information  on  the  screen  and/or  share  that  information 
with  distant  modules.  VBDS  software  capability  to  "draw"  this  information  using 
keyboard  commands  existed,  but  was  quite  difficult  to  learn  and  mastered  by  only  a  few 
"visually  oriented"  soldiers. 


Limited  communications  capabilities  in  the  corps  area  required  a  conservative 
data  update  philosophy  to  reduce  the  heavy  burden  imposed  by  graphic  display  data. 
SPADS'  strategy  was  to  transmit  only  overlay  data  by  electrical  means;  backgrounds  such 
as  maps  or  chart  matrices  were  to  be  pre-positioned  at  all  locations  or  delivered  by  courier 
on  floppy  disk.  Only  the  Briefing  and  Current  Situation  overlays  that  changed  data  were 


sent  through  the  communications  network.  This  feature  could  reduce — by  1,000  percent — 
the  communications  load  over  what  would  have  been  required  if  complete  graphics  had  to 
be  transmitted  throughout  the  network. 

a.  Pros: 

The  transmission  of  "exception  data"  certainly  reduced  the  communications 
load  imposed  by  employing  a  graphics-oriented  decision  support  system.  DAGMaR,  a 
successful  solution  that  incorporated  links  between  the  decision  graphics,  data  base,  and 
spreadsheet.  In  fact,  DAGMaR  was  able  to  transmit  only  the  changed  values  from  the 
spreadsheet  tr  produce  updated  graphics  for  all  recipients. 

b.  Cons: 

The  original  graphics  programs — commercial  products  incorporated  into 
SPADS — were  too  cumbersome  to  use,  so  few,  if  any,  backgrounds  were  completed 
before  they  were  needed.  Bi-daily  courier  runs  were  not  timely  enough  to  carry  critical 
graphics  needed  for  Current  Situation  software.  The  staff  users  were  thus  forced  to 
transmit  entire  graphics  throughout  the  system  and  thereby  reduced  the  capacity  of  the 
network  by  a  factor  of  ten.  This  seriously  strained  the  capacity  of  the  early  gateways,  and 
imposed  a  severe  load  on  the  tactical  communications  system. 

4 .  Maintain  Continuity  of  Operations. 

This  critical  requirement  influenced  both  SPADS  equipment  configuration  and 
recommended  employment  concept.  The  basic  philosophy  was  to  design  for  graceful 
degradation.  If  part  of  a  staff  duty  station,  or  part  of  an  entire  module  should  fail,  the 
remaining  components  would  continue  to  operate.  Specific  design  features  incorporated 
were  as  follows: 


m 


1 .  Distributed  intelligent  staff  duty  stations  were  selected  rather  than  traditional,  less 
capable  work  stations  serviced  by  a  multi-user  central  computer.  If  a  staff  duty 
station  failed,  the  highest  priority  tasks  could  be  completed  on  remaining  stations. 
Each  staff  user  had  dedicated  equipment  so  that  he/she  did  not  compete  for 
processing  resources  during  crisis  periods. 

2.  A  medium-speed  printer  provided  hard  copy  messages  and  ensured  essential  record 
traffic  was  maintained  in  the  event  of  a  major  system  failure. 

3 .  A  direct  access  communications  (DAC)  interface  to  and  from  selected  high  priority 
staff  duty  stations  provided  timely  communications.  DAC  accomplished  this  despite 
substantial  traffic  backlogs  and  provided  manual  interfaces  to  other  microcomputer- 
based  systems,  such  as  TAP. 

4.  The  data  bases,  Current  Situation  briefings,  and  map  videodiscs  were  duplicated  at 
each  module.  Enough  data  existed  at  each  module  to  replicate  the  functions  of  any 
other  module  should  one  be  destroyed  or  otherwise  lost  from  the  network. 

a.  Pros: 
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Since  all  staff  duty  stations  were  intelligent  microcomputers,  staff  sections 
could  use  commercial  software  to  compensate  for  capabilities  not  provided  by  SPADS 
software.  Each  module's  shared  output  station  (SOS) — the  medium-speed  printer — was 
critical  for  printing  and  distributing  OPLANS  and  OPORDS  or  lengthy  data  base  reports. 
In  addition,  all  FLASH  message  traffic  for  each  user  was  automatically  printed  at  the  SOS. 
The  DAC  provided  the  ability  to  "network"  non-connected  equipment  suites  such  as 
SPADS  and  TAP.  Replication  of  hardware  and  software  at  each  module  was  reinforced  by 
corps  SOPs  and  staff  organization  that  placed  complimentary  personnel  at  each  module  to 
maintain  continuity  of  operations, 
b.  Cons: 

Although  the  staff  duty  stations  were  state-of-the-art  in  1981,  they  were  not 
upgraded  throughout  the  lifetime  of  SPADS.  Compared  to  later,  more  capable 
microcomputers,  the  system's  components  were  merely  able  to  hold  established  ground  as 
demands  on  the  system  increased.  The  DAC  was  actually  a  work-around  for  the  real 
solution,  which  would  have  been  to  net  SPADS  and  TAP;  unfortunately  this  was  not  a 
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funding  priority,  so  information  had  to  be  extracted  from  either  system  and  then  typed  in 
again  by  the  operator. 


5 .  Provide  Computational  Support. 

Each  staff  section  in  a  module  might  have  its  own  set  of  requirements  for 
analysis,  such  as  generating  spreadsheets  or  personnel  and  equipment  status  reports,  or  for 
creating  local  data  bases.  SPADS  was  designed  to  provide  the  capability  to  execute  non- 
SPADS  programs  and  to  create  local  programs  to  meet  the  needs  of  each  staff  section.  This 
capability  ensured  maximum  utilization  of  existing  programs  and  enabled  staff  sections  to 
develop  software  tailored  to  their  unique  needs, 
a.  Pros: 


Initially  SPADS  had  no  number-crunching  capabilities,  so  various  staff 
sections  took  advantage  of  the  commercial  program  Visicalc1  to  meet  their  needs.  Certain 
functional  algorithm  software  had  been  developed  by  the  Command  and  Control 
Microcomputer  Users  Group  (C2MUG),  headquartered  at  Fort  Leavenworth,  KS,  that 
could  be  executed  on  the  staff  duty  stations.  Programs  for  weather,  NBC,  force 
projection,  and  logistics  were  frequently  used, 
b.  Cons: 
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Users  were  continually  frustrated  in  their  efforts  to  share  the  results  of  their 
local  applications  with  distant  users  since  SPADS  did  not  support  any  transmission 
standards  but  its  own.  When  SPADS  finally  got  a  spreadsheet,  users  welcomed  it  until 
they  found  it  was  vastly  inferior  to  the  software  they  had  given  up.  Furthermore,  "home¬ 
grown'1  programs  written  to  run  on  the  SPADS  operating  system  quite  often  crashed  the 


1  Visacalc  is  a  registered  trademark  of  Software  Arts,  Cambridge,  Massachusetts. 
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entire  local  area  network  if  they  had  any  failures,  and  sometimes  could  even  create  havoc 
inside  of  the  operating  system  itself. 

6.  Develop  a  User-Friendly  System 

Using  familiar  formats  and  simple  equipment  would  ensure  effective  operation  in 
the  stress  of  Field  use.  Ideally,  the  SPADS  design  principles  would  consistently  involve 
the  following  concepts: 

1.  The  SPADS  program  provided  prompts  to  the  operator  on  steps  necessary  to 
perform  each  function 

2 .  The  automated  map  display  used  images  of  standard  Army  maps  stored  on  videodisc 
to  present  a  display  identical  to  the  working  maps  used  in  the  tactical  c  xranand  posts 

3 .  The  graphics  backgrounds  and  message  formats  were  designed  to  look  similar  to  the 
paper  message  formats  currently  in  use;  users  adapted  SPADS  to  conventional 
formats  whenever  desired 

a.  Pros: 

Several  programs  were  powerful,  flexible  and  concise;  they  had  good  visual 
prompts  and  useful  help  menus.  The  VBDS  images  were  identical  to  the  standard  tactical 
maps  on  the  walls  of  the  command  posts. 

b.  Cons: 

Most  programs  running  under  the  SPADS  main  command  line  were  "user- 
hostile";  they  provided  incomplete  on-screen  clues  that  were  meaningful  only  to  the 
programmers,  many  had  no  help  screens  at  all,  and  a  few  allowed  no  mistakes  in,  or 
escapes  from,  tedious  sequences  of  input  and  keypresses.  Quite  often  undocumented 
features  from  previous  versions  of  programs  were  left  on  the  system  for  the  unwary  user  to 
stumble  onto  with  unpredictable  results. 

The  ideal  of  common  backgrounds  was  almost  never  achieved  due  to  the 
severe  difficulty  in  manipulating  the  graphics  programs  to  look  like  standard  formats.  Most 
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staff  officers  either  put  up  with  what  was  already  on  the  screen  or  merely  employed  blank 
backgrounds  rather  than  fighting  with  the  system. 
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7 .  Provide  a  Rugged,  Low-cost  System 

SPADS  used  commercial  microcomputer  equipment  modified  for  field  use,  the 
time  to  develop  and  field  SPADS  was  about  one-fifth  of  a  normal  development  cycle 
because  of  the  use  of  off-the-shelf  commercial  products.  This  also  maintained  low  costs. 
Obviously,  it  was  necessary  to  take  some  steps,  without  attempting  full  militarization,  to 
ensure  that  the  system  would  perform  well  in  the  field.  First,  the  microcomputers  were 
modified  by  the  addition  of  a  backplane  that  provided  simple  connections  between  the 
computer  and  other  devices  in  the  system.  This  circumvented  the  need  to  open  the 
microcomputer  case  and  expose  sensitive  parts  in  order  to  make  connections.  Second, 
special  transport  cases  were  designed  to  protect  the  equipment  during  transportation  and 
provide  the  physical  support  for  each  work  station, 
a.  Pros: 

The  use  of  nondevelopmental  item  (NDI)  equipment  certainly  accelerated  the  arrival 
of  SPADS  to  the  operational  user.  Existing  operating  systems  and  programming  languages 
for  these  microcomputers  further  accelerated  program  development.  Use  of  backplanes 
made  it  easier  for  the  SPADS  operator  to  learn  to  install,  operate  and  maintain  the 
equipment.  The  special  transport  cases  were  extremely  rugged  and  sufficiently  protected  all 
of  the  equipment  from  severe  abuse  during  transportation  and  field  employment, 
b.  Cons: 

The  microcomputers  selected  were  the  most  powerful  available  during  the 
system  start.  Unfortunately  as  newer,  more  powerful,  and  less  expensive  microcomputers 
rapidly  became  available,  SPADS  was  stuck  with  its  original  staff  duty  stations,  and  no 
amount  of  modifications  later  on  could  increase  either  capacity  or  processing  power.  The 
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backplanes  were  a  quick  idea  that  wasn't  thought  through;  the  connections,  while  simple, 
were  much  too  fragile  for  field  tests,  and  equipment  was  frequently  out  of  commission 
because  it  couldn't  be  connected  to  the  LAN.  The  transport  cases  were  extremely  effective, 
but  their  handles  and  closures  seemed  to  have  been  added  as  design  afterthoughts. 

B  .  SPADS  PROGRAM  RECOMMENDATIONS 

Reviewing  the  history  of  SPADS’  evolutionary  development  program,  certain  lessons 
can  be  derived  for  planning,  training,  communications  support,  and  procedures.  These 
lessons  are  applicable  to  any  new  C2  system,  but  are  especially  important  to  a  program  that 
evolves  over  time  based  upon  the  lessons  learned  by  its  operational  users. 

First,  SPADS  needed  the  V  Corps  commander's  emphasis — from  the  time  the  original 
request  for  assistance  was  sent  to  DNA  through  the  end  of  OC3.  In  1982,  McGrew  and 
Jutte  observed  the  fledgling  SPADS  experiment  during  Caravan  Guard  HI;  at  that  time  they 
noted  the  critical  necessity  of  getting  the  commander  and  staff  behind  the  project  to  ensure 
its  success  [Ref.  12:pp.  21-22].  As  new  commanders  took  control  of  the  corps,  their 
interests  in  SPADS  changed  with  what  they  perceived  it  could  do  for  them  at  any  given 
time.  Unfortunately  SPADS  could  not  be  an  effective  command  and  control  tool  unless  the 
commander  insisted  on  its  use  for  his  critical  decision  making  information.  This  was  not 
consistently  the  case  until  the  spring  of  1984,  after  C2IO  had  been  created  to  manage  the  V 
Corps  C2  system. 

After  the  commander's  expressed  interest,  the  next  major  problem  was  training 
personnel  to  use  SPADS  in  accordance  with  established  command  post  procedures.  Once 
again,  there  was  not  real  progress  in  this  area  until  the  C2IO  had  been  established.  Prior  to 
that  time,  the  major  lessons  learned  relating  to  training  were: 

1 .  Every  module  needed  dedicated  SPADS  operators 

2 .  Operators  required  formal  training 


3.  NCOs  and  staff  officers  needed  training  which  emphasized  the  interpretation  ot 
outputs  as  well  as  SPADS  operating  procedures 

4.  Operator  proficiency  could  only  be  maintained  in  garrison  by  using  the  system 
capabilities  to  perform  peacetime  functions 

5 .  A  regular  training  plan  that  included  periodic  refresher  training  was  required 

6.  Trainees  had  to  be  able  to  attend  SPADS  training  without  interruptions 

7 .  A  "field-proof'  quick  reference  guide  was  needed  to  supplement  the  User's  Manual 
A  corollary  of  the  training  problem  was  a  total  lack  of  established,  SPADS-based 

command  post  procedures.  The  DCP  program  started  at  V  Corps  in  1981;  until  the  V 
Corps  DCP  LOI  was  distributed  in  the  spring  of  1985,  the  only  SOP  written  for  SPADS 
involved  Current  Situation.  Three  recommendations  that  would  have  greatly  increased  the 
effective  use  of  SPADS  throughout  the  OCs  are: 

1 .  Develop  written  procedures  for  the  use  of  SPADS  and  for  internal  processing  of 
SPADS  information 

2 .  Require  and  enforce  scheduled  updates  of  all  reports  required  through  SPADS 

3.  Ensure  that  the  system  is  ready  before  field  use;  clean  out  the  data  bases  and  fill 

Current  Situation  with  briefings 

In  the  realm  of  technology  and  communications,  V  Corps  had  a  critical  need  for  on-site 
expertise  to  guide  the  system  from  initial  fielding  through  full  operation.  The  expertise  was 
available — in  the  Communications-Electronics  staff  and  the  Signal  Brigade — but  those 
experts  were  not  tasked  by  the  commander  to  participate  in  this  project.  They  could  have 
assisted  operational  users  in  defining  the  critical  information  needs  of  the  commander  and 
staff.  They  certainly  could  have  ensured  the  selection  of  the  four-wire  autodial  modems 
needed  from  the  beginning  of  the  DCP  experiments  that  were  never  fielded.  Finally,  they 
could  have  planned  the  field  use  and  development  of  SPADS  so  that  communication 
requirements  complemented  the  scarce  signal  resources  of  the  corps,  rather  than 
exacerbated  them. 
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C.  EVOLUTIONARY  DEVELOPMENT  CONCLUSIONS 

Throughout  the  1980s,  Army  C3  systems  were  being  proposed  to  satisfy  operational 
users’  needs  from  division  through  theater  levels.  The  principal  system  in  the  Army 
Command  and  Control  Master  Plan  during  the  past  decade  has  been  the  Maneuver  Control 
System  (MCS).  MCS  is  a  product  of  the  traditional  concept-based  requirements  definition 
process.  MCS  is  envisioned  as  a  fully  militarized,  general  purpose,  data  processing, 
display  and  communications  system  designed  to  be  the  backbone  of  Army  tactical  C2  [Ref. 
25:pp.  56-57],  Although  originally  scheduled  for  fielding  in  the  mid-1980s,  mounting 
costs  and  program  slippages  have  (almost)  annually  put  the  system  in  jeopardy  before 
Congress. 

The  evolutionary  development  approach  used  throughout  the  SPADS  program  met  the 
immediate  command  and  control  requirements  of  military  users  while  maintaining  flexibility 
to  respond  to  changing  requirements  and  advancing  technology.  The  use  of  carefully 
selected  and  configured  off-the-shelf  commercial  products  put  the  components  of  the  first 
operational  capability  in  the  field  in  months  instead  of  years.  Starting  in  September  1981, 
V  Corps  operational  users  were  immediately  able  to  test  system  capabilities  as  well  as  C2 
procedures  during  each  field  test  and  exercise. 

System  enhancements  and  corrections  were  made  within  each  operational  capability 
cycle  by  adding  or  replacing  hardware  components  and  by  integrating  new  software 
tailored  to  meet  specific  military  requirements.  Subsequent  OC  cycles  consolidated 
incremental  enhancements  or  involved  system  upgrades  which  took  advantage  of  major 
advances  in  microcomputer  technology.  [Ref.  26:pp.  60-63] 

Three  of  SPADS’  key  achievements  within  V  Corps  were:  (1)  helping  define 
commander  and  staff  C2  requirements,  (2)  providing  a  basis  for  conceptual  and  doctrinal 
development,  and  (3)  putting  a  C2  capability  into  the  field  in  the  near  term.  In  August 


%■ 


1984,  the  TRADOC  Deputy  Chief  of  Staff  for  Combat  Developments  wrote  [Ref.  25:pp. 
55-56]: 

One  of  the  programs  the  Army  is  evaluating  is  called  the  Staff  Planning  and  Decision 
Support  System  (SPADS)....The  experience  the  Army  is  gaining  in  SPADS 
and. ..related  programs  is  directly  guiding  the  evolution  of  our  Maneuver  Control 
System  (MCS). 

D.  MCES  APPLICATION  CONCLUSIONS 

Other  NPS  degree  students  who  employed  MCES  were  able  to  draw  from  either  an 
established  body  of  work  or  a  team  of  experts  when  evaluating  their  chosen  C2  systems. 
Since  SPADS  was  a  unique  exploratory  program,  this  researcher  hud  no  such  traditional 
sources  for  guidance  or  assistance.  In  addition,  SPADS  had  already  completed  its 
evolutionary  life  cycle  from  concept  through  three  operational  capability  stages  to  fully 
deployed  system.  During  that  term  there  had  been  two  highly  unfavorable  evaluations  by 
the  U.S.  Army  TCATA;  in  fact,  one  deputy  director,  Mr.  Reedie  A.  Stone,  Jr.,  stated: 
"With  respect  to  SPADS,  it  didn't  work  and  I  recommend  that  the  corps  contact  the  GSA 
for  disposal  instructions1’’  In  direct  contrast  to  this,  the  DNA  Program  Manager  for 
SPADS,  LTC  Robert  E.  Laird,  stated:  "DNA  considered  SPADS  as  success  as  a  proof  of 
concept."1  It  was  obvious  at  the  outset  that  an  objective  evaluation  of  SPADS  using  the 
MCES  would  present  some  challenges. 

The  Modular  Command  and  Control  Evaluation  Structure  proved  itself  to  be  a 
robust  and  powerful  framework  for  evaluating  the  Staff  Planning  and  Decision  Support 
system.  It  was  flexible  enough  to  evaluate  the  three  problem  areas  presented  in  Chapter  I 

■Letter  addressed  to  author  by  Mr.  R.  Stone,  Deputy  Director,  BATD,  TEXCOM, 
Subject:  Request  for  Information  on  the  Staff  Planning  and  Decision  Support  System, 
dated  14  December  1987. 

2  Phone  conversation  with  LTC  Laird,  23  November  1987. 


under  four  different  evolutionary  conditions.  The  evaluations  proceeded  iteratively  from 
the  V  Corps  baseline  through  the  three  operational  capabilities. 

Throughout  Chapters  III,  IV,  and  V  this  thesis  specifically  assessed  SPADS' 
effectiveness  for  the  following  three  problems: 

1 .  Did  SPADS  provide  the  V  Corps  commander  and  his  staff  with  the  ability  to  exercise 
command  and  control  of  combat  assets  to  meet  overall  mission  objectives? 

2.  Did  SPADS  demonstrate  that  the  dispersed  command  post  concept  enhanced 
command  survivability? 

3.  Did  SPADS  evolve  as  a  command  and  control  force  effectiveness  system  for  the  V 
Corps  DCP  based  upon  operational  lessons  learned? 

The  resolution  of  the  first  problem  required  a  measure  of  effectiveness  that  was 
derived  from  the  three  pan  definition  of  a  C3  system.  This  problem  addressed  C2  mission 
orientation  in  terms  of  the  C2  process,  structural  components,  and  physical  entities  for  the 
evolving  interaction  between  SPADS  and  the  V  Corps  Dispersed  Command  Post  concept. 
The  Summaries  of  Chapters  III,  IV,  and  V  individually  addressed  the  changing  aspects  of 
this  problem.  Figure  6.1  provides  graphic  evidence  that  SPADS  provided  the  commander 
and  his  staff  increasing  value  for  C?  mission  orientation,  XMOTi,  throughout  the  three 
year  experiment. 

The  second  problem  addressed  command  survivability,  in  terms  of  the  facilities, 
equipment,  procedures,  personnel  and  information  flow  patterns  that  made  up  the  V  Corps 
Dispersed  Command  Post.  Until  the  V  Corps  commander  and  staff  provided  effective 
leadership  and  management  of  SPADS  during  OC3,  command  survivability  increased  only 
slightly  in  value.  After  the  C2IO  was  established,  the  staff  sections  and  elements  of  each 
command  post  received  the  expertise  required  to  consistently  increase  command 
survivability.  The  center  section  of  Figure  6.1,  XCSTi,  clearly  shows  that  SPADS. 
together  with  the  DCP,  enhanced  survivability  during  the  last  operational  capability  cycle. 
The  third  problem  measured — across  levels  of  operational  capacity — the  evolution  of  C2 


force  effectiveness  together  with  survivability.  This  final  measure  of  command  and  control 
evolution  was  derived  as  a  function  of  the  MOFE  from  Problem  1  and  the  MOE  from 
Problem  2,  with  respect  to  time.  The  C2/FE  layer  in  Figure  6. 1  graphically  reinforces  the 
conclusions  reached  in  Chapters  in,  IV,  and  V.  As  SPADS  evolved  from  August  1981  to 
March  1985,  it  provided  distinct  advantages  to  V  Corps  in  terms  of  C2  force  effectiveness, 
C2  mission  orientation,  and  command  survivability. 

E.  MCES  RECOMMENDATIONS 

1.  Further  Testing  and  Refinement 

MCES  is  a  powerful  evaluation  framework;  like  any  such  system  or 
methodology,  it  has  a  steep  learning  curve.  The  only  way  to  learn  to  use  MCES  is  by 
applying  the  seven  iterative  modules.  Any  analyst  interested  in  employing  MCES  would  be 
well-advised  to  both  examine  the  written  results  of  previous  evaluations  and  to  begin 
applying  the  methodology  as  soon  as  possible — ideally  with  guidance  from  an  analyst  that 
has  applied  MCES  in  a  similar  problem  area. 

The  present  literature  on  MCES  presents  a  diverse  approach  to  this  evolving 
methodology.  One  refinement  to  MCES  that  would  allow  analysts  and  decision  makers  to 
communicate  more  effectively  throughout  the  MCES  evaluation  process  would  be  a 
glossary  or  "thesaurus"  of  MCES  terminology  and  concepts.  Another  valuable  effort 
would  be  the  pooling  of  previous  MCES  evaluations  into  a  knowledge  base  that  could  be 
used  to  develop  a  microcomputer-based  toolset  for  the  MCES  analysts. 

2  .  Education  and  Dissemination 

The  MCES  is  a  systems  approach  to  the  evaluation  of  C2  systems.  It  is  a 
valuable  framework  for  any  planner,  engineer,  or  analyst  who  is  charged  with  evaluating 
C2  systems  at  any  stage  of  development  in  the  defense  acquisition  process. 
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Comparison  of  the  Three  Measures  Across  AH  Exercises 


The  Modular  Command  and  Control  Evaluation  Structure  is  a  flexible 
framework  that  would  add  great  value  to  an  appropriate  course  in  the  C3  curriculum  at  the 
Naval  Postgraduate  School.  The  experience  gained  from  applying  MCES  in  a  controlled 
academic  setting  would  assist  C3  graduates  in  future  assignments.  MCES  can  assist  the 
military  officer  in:  identifying  C3  system  requirements;  applying  operational  experience  and 
technical  knowledge  to  evaluate  the  effectiveness  of  C2  systems;  evaluating  R&D  projects 
as  well  as  technical  and  engineering  studies;  integrating  the  results  for  near-  and  long-term 
C3  system  improvements;  planning  C3  aspects  of  operations,  exercises,  and  tests;  and 
developing  joint  C3  systems  plans,  operating  concepts,  and  policy. 

Future  C3  graduates  who  have  used  MCES  in  their  academic  work  at  NPS  will 
be  better  able  to  fulfill  their  responsibilities  in  the  field  of  command,  control,  and 
communications.  That  experience  will  assist  them  in  their  efforts  to  analyze  the  technical 
and  operational  aspects  of  C3  environments  as  they  effectively  interface  with  engineers, 
planners,  and  operational  personnel  in  the  development  of  new  C3  systems  and  the 
improvement  of  old  systems. 


> ) 


APPENDIX  A 

GLOSSARY  OF  ACRONYMS  AND  ABBREVIATIONS 

AC 

Alternating  current 

ACofS 

Assistant  Chief  of  Staff 

ACR 

Armored  cavalry  regiment 

ACTO 

Army  Communicative  Technology  Office/action  officer 

ADA 

Air  defense  artillery 

ADE 

Air  defense  element 

ADM 

Atomic  demolition  munitions 

AFSOUTH 

Air  Forces  Southern  Europe 

ALO 

Air  Liaison  Officer  (Air  Force) 

ALT 

Alternate 

AMO 

Automation  management  officer/office 

APP 

Appendix 

ARI 

Army  Research  Institute 

ASIC 

All  Source  Intelligence  Center  (Intelligence  module) 

ASOC 

Air  Support  Operations  Center  (Air  Force) 

ATC 

Air  traffic  control 

ATK 

Attack 

AVN 

Aviation 

AUTODIN 

Automatic  Digital  Network 

AUTOSEVCOM 

Automatic  Secure  Voice  Communications 

AUTOVON 

Automatic  Voice  Network 

AVAIL 

Available 

B&G 

Black  and  green  (monochrome) 

BCC 

Battle  Control  Center  (Air  Force) 

BIRS 

Battlefield  Information  Reporting  System  (SPADS 

DBMS) 

BIRSEN 

BIRS  input  report 

BPS 

Bits  per  second 

C2 

Command  and  control 

C2IO 

Command  and  Control  Initiatives  Office  (V  Corps) 
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C-MUG 

C3 

C3CM 

C3I 

CACDA 

CATDA 

CAM 

CAS 

CAME 

CBC 

CBM 

CCA 

CCIR 

CDR 

CE 

CECOM 

CENTAG 

CEOI 

CFV 

CGS 

CLiP 

CMB 

CMD 

CMO 

COM 

COMM 

COMSEC 

CONUS 

COSCOM 

CP 

CPU 

CPX 

CRC 

CRYPTO 


Command  and  Control  Microcomputer  Users  Group 
Command,  control  and  communications 
Command,  control  and  communications  countermeasures 
Command,  control,  communications  and  intelligence 
Combined  Arms  Combat  Development  Activity 
Combined  Arms  Training  Development  Activity 
Common  area  maintenance  (SPADS  function) 

Close  air  support 

Corps  Airspace  Management  Element 
Current  battle  cell 
Current  battle  module 

Command  and  Control  Automation  Office  (V  Corps) 
Commander's  critical  information  requirements 
Commander 

Communication-Electronics 
Communication-Electronics  Command 
Central  Army  Group  (NATO) 

Communications  electronics  operating  instructions 
Combat  fighting  vehicle 

Communications  gateway  station  (SPADS  hardware) 
Communications  link  processor  (SPADS  hardware) 
Collection  management  branch  (Intelligence  module) 
Command 

Civil-military  operations 
Center  of  mass 
Communications 
Communications  security 
Continental  United  States 
Corps  support  command 
Command  post 
Central  processing  unit 
Command  post  exercise 
Cyclical  redundancy  check 
Cryptographic 
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CSMA 


CSS 

croc 

CTOCSE 

DAC 

DAGMaR 

DATEX 

DAViD 

DBMS 

DBP 

DCP 

DCSOPS 

DEMO 

DISCOM 

DIV 

DIVARTY 

DMD 

DNA 

DOD 

DP 

DTAC 

DTD 

DTG 

DTMF 

DTOC 

ECC 

ECCM 

ECM 

ECP 

EDP 


Communications  Secunty  Maintenance  Agency/ 

carrier  sense  multiple  access 

Combat  service  support 

Corps  tactical  operations  center 

CTOC  support  element  (Intelligence  module) 

Direct  access  communications  (SPADS  software) 

Data  and  graphics  manufacture  and  retrieval  (SPADS 
software) 

West  German  data  network  of  the  Deutsches  Bundespost 
Data  automated  video  display  (SPADS  II  software) 
Database  Management  System 

Deutsches  Bundespost  (West  German  telecommunications 
agency) 

Dispersed  command  post 

Deputy  Chief  of  Staff  for  Operations 

Demonstration 

Division  support  command 

Division 

Division  artillery 

Digital  message  device  (TACFIRE  hardware) 

Defense  Nuclear  Agency 
Department  of  Defense 
Dimensional  parameters 
Division  tactical  command  post 
Dated 

Date  time  group 
Dual  tone  multiple  frequency 
Division  tactical  operations  center 
Exercise  Control  Center 
Electronic  counter-countermeasures 
Electronic  countermeasures 

External  communication  processor  (SPADS  hardware) 
Exploratory  Development  Program 


EMP 


EMS 

ENGR 

EPW 

ESM 

EST 

EVAL 

EW 

EXER 

FA 

FAC 

FAIR 

FC 

FLOT 

FLOTREP 

FM 

FORSCOM 

FRAGO 

FSCOORD 

FSE 

FSM 

FTX 

FY 

GI 

G2 

G3 

G4 

G5 

GATEWAY 

GFE 

GMGR 

GSA 


Electronic  mail  processor  (SPADS  hardware)/ 

electromagnetic  pulse 

Electronic  Mail  System  (SPADS  software) 

Engineer 

Enemy  prisoners  of  war 

Electronic  security  measures 

Estimate 

Evaluation 

Electronic  warfare 

Exercise 

Field  artillery 

Forward  air  controller  (Air  Force) 

MOE  for  evaluating  C2  Process  (flexibility, 
availability,  interoperability  ,and  responsiveness) 
Field  Circular 

Forward  Line  of  Own  Troops 
FLOT  report 

Field  manual/frequency  modulation 
Forces  Command  (Army) 

Fragmentary  order 

Fire  support  coordination  officer 

Fire  support  element 

Fire  support  module 

Field  training  exercise 

Fiscal  year 

ACofS  Gl,  Personnel  and  Administration 

ACofS  G2,  Intelligence 

ACofS  G3,  Operations 

ACofS  G4,  Logistics 

ACofS  G5,  Civil-Military  Operations 

Communications  gateway  station  (SPADS  hardware) 

Government  furnished  equipment 

Gateway  Manager  (SPADS  software) 

General  Services  Agency 
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HEL 

Helicopter 

HP ITS 

DAC  software  (SPADS) 

HQ 

Headquarters 

HZ 

Hertz  (cycles  per  second) 

ID 

Identify/identification 

IFFN 

Identification,  Friend,  Foe  or  Neutral  Joint  Testbed 

IFP 

Interfile  Processor  (SPADS  software) 

IMP 

Intermodule  communications  processor  (SPADS 
hardware) 

INCL 

Inclosed/included 

INFO 

Information 

INTEL 

Intelligence 

INTSUM 

Intelligence  summary 

IOC 

Initial  operational  capability 

IR 

Intelligence  requirement 

JAAT 

Joint  air  attack  team 

JCS 

Joint  Chiefs  of  Staff 

KBYTE 

Kilobyte 

KM 

Kilometer 

KT 

Kilotons 

LAN 

Local  area  network 

LANCE 

Nuclear-capable  field  artillery  system 

LNO 

Liaison  officer/office 

LOG 

Logistics 

LOI 

Letter  of  Instruction 

LTC 

Lieutenant  Colonel  (Army) 

LTCOL 

Lieutenant  Colonel  (Air  Force) 

MAIN 

Main  command  post 

MBYTE 

Megabyte 

MBPS 

Megabyte  per  second 

MCES 

Modular  Command  and  Control  Evaluation  Structure 

MCS 

Maneuver  Control  System  (Army  C2  system) 

METT-T 

Mission,  enemy,  terrain,  troops  and  time  available 

MICRO 

Microcomputer/microprocessor 
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MICROFIX 

Army  intelligence  workstation  program 

MLRS 

Multiple  Launch  Rocket  System 

MM 

Millimeter 

MOE 

Measure  of  effectiveness 

MOFE 

Measure  of  force  effectiveness 

MOP 

Measure  of  performance 

MORS 

Military  Operations  Research  Society 

MP 

Military  Police 

MSE 

Mobile  Subscriber  Equipment 

MSR 

Major  supply  route 

MSS 

Mass  storage  station  (SPADS  hardware) 

MUX 

Multichannel  communications 

NBC 

Nuclear,  biological  and  chemical 

NCO 

Noncommissioned  officer 

NCP 

Network  control  processor  (SPADS  hardware) 

NCS 

Network  control  station 

NDI 

Nondevelopmental  item 

NETT 

New  equipment  training  team 

NLT 

Not  later  than 

NPS 

Naval  Postgraduate  School 

O/H 

Quantity  on-hand 

OB 

Order  of  Battle  (SPADS  DBMS) 

OC 

Operational  capability 

OE 

Organizational  effectiveness 

OJT 

On-the-job  training 

OMNINET 

SPADS  local  area  network 

OPCON 

Operational  control 

OPLAN 

Operations  plan 

OPNS 

Operations 

OPORD 

Operations  order 

OPS 

Operations 

OPSEC 

Operations  security 

PDR 

Power  distribution  and  regulation 

PIR 

Priority  intelligence  requirement 

PLU 

PMB 

POCE 

PP 

PSYOP 

PTT 

PUB 

QTR 

R&D 

RAOC 

REF 

RF^ORGER 

REQ 

S&FC 

SDI 

SDS 

SHAPE 

SIGSEC 

SITREP 

SOP 

SOS 

SOW 

SPADS 

SPADS  n 

SPOTREF 

SPT 

STARTEX 

SUPCOM 

SWO 

SYMTEC 

TACCP 

TACAIR 

TACFIRE 

TACIP 


Position  location  uncertainty 

Production  management  branch  (Intelligence  module) 

Proof  of  concept  experiment 

Pages 

Psychological  operations 
Post  Telephone  Telegraph 
Publication 
Quarter 

Research  and  development 
Rear  Area  Operations  Center 
Reference 

Return  of  Forces  to  Germany  (Annual  exercise) 
Required 

Store  and  Forward  Concentrator  (Gateway  software) 

Strategic  Defense  Initiative 

Staff  duty  station  (SPADS  hardware) 

Supreme  Headquarters  Allied  Powers  Europe 

Signal  security 

Situation  report 

Standing  operating  procedure 

Shared  output  station  (SPADS  hardware) 

Statement  of  work 

Staff  Planning  and  Decision  Support  System 
UDDAS  (USAREUR  HQ's  experimental  C2  system) 
Spot  report 
Support 

Start  of  exercise 
Support  command 

Staff  weather  officer/office  (Air  Force) 

Graphics  overlay  device  (SPADS  hardware) 

Tactical  command  post 
Tactical  air  support 

Army  field  artillery  command  and  control  system 
The  Army  Command  and  Control  Initiative  Program 
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TACP 

TAP 

TASKORG 

TASS 

TCATA 

TCT 

TGT 

TIB 

TNF 

TOC 

TOPO 

TOW 

TRADOC 

TTY 

ucc 

UDDAS 


UPS 

USA 

USAF 

USAFE 

USAREUR 

VBDS 

VCR 

VDP 

VOL 

WINTEX 

WWMCCS 

wx 

XT  EL 


Tactical  air  control  party  (Air  Force) 

Target  Acquisition  and  Planning  system 
Task  organization  report 
Tactical  Army  Switching  System 
TRADOC  Combined  Arms  Test  Activity 
Tactical  Computer  Terminal  (MCS  hardware) 
Target/targeting 

Target  intelligence  branch  (Intelligence  module) 

Theater  nuclear  forces 

Tactical  operations  center 

Topographic 

Gu’  led  antitank  missile 

Training  and  Doctrine  Command  (US  Army) 

Teletypewriter 

Umpire  Control  Center 

USAREUR  Distributed  Decision  Aids  System 

(USAREUR  HQ’s  experimental  C2  system) 

Uninterruptable  power  supply 

U.S.  Army 

U.S.  Air  Force 

U.S.  Air  Forces  Europe 

U.S.  Army  Europe 

Video  battlefield  display  system  (SPADS  software) 
Videocassette  recorder 
Videodisc  package 
Volume 

Biannual  winter  exercise  in  Germany  (Army) 
Worldwide  Military  Command  and  Control  System 
Weather 
Crossteil  process 
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APPENDIX  B 

SPADS  STATEMENT  OF  WORK1 


Task  1:  V  CORPS  SUPPORT.  Provide  software  support  to  V  Corps  during 
REFORGER  81,  Able  Archer  81,  Crested  Eagle  82: 

(1)  Plan,  train,  assist,  and  report 

(2)  Applications/data  base  development 

Task  2:  DCP  CONCEPTS.  Identify  and  test  feasible  information  exchange 
concepts  for  DCP: 

(1)  Communications  networking 

(2)  CONUS  testing 

Task  3:  CARAVAN  GUARD  SUPPORT.  Contractor  shall  support 
V  Corps  test  of  DCP: 

(1)  Plan,  train,  assist,  report 

(2)  Develop  SOP  for  dispersed  operations  using  microcomputer  equipment 

(3)  Communications  gateway  software  development 

(4)  Deliverables 

Task  4:  PTT  MANAGEMENT  INTERFACES/PROCEDURES.  Document  and 
demonstrate  how  the  DCP  can  utilize  the  Deutsche  Bundespost  (DBP): 

( 1 )  Document  management  procedures/interfaces 

(2)  DATEX  test 

Task  5 :  V  CORPS/8  ID  COMMAND  AND  CONTROL  DOCTRINE 
EVALUATION: 

(1)  Develop  a  capability  to  evaluate,  through  evolutionary  testing, 
the  effectiveness  of  and  requirements  for  emerging  Army  doctrine 
on  dispersed  field  C2 

(2)  The  principal  effort  will  be  to  develop  a  testbed  for  providing  an 
information  distribution  and  processing  system  between  the  corps, 
division,  and  corps/division  command  elements 

(3)  The  final  test  plan  will  provide  a  basis  for  documenting  and 
evaluating  the  results  of  the  theoretical  efforts  related  to  the 
internal  corps  and  division  C2  operations 


'SOURCE:  LTC  Robert  Laird,  Defense  Nuclear  Agency,  UNCLASSIFIED  Letter  to 
the  author,  Subject:  SPADS,  23  November  1987. 
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Task  6:  NUCLEAR  AIR  BATTLE  MANAGEMENT  (Conducted  for  USAFE) 

Task  7:  SUPPORT  FOR  REFORGER  AND  ABLE  ARCHER: 

(1)  Provide  "on-site"  contractor  liaison  support  for  V  Corps 

(2)  REFORGER  1982  support 

(3)  Operational  test  of  full- up  DCP  concept 

(4)  Assist  V  Corps  in  developing  SOPs  required  to  operate  effectively 
in  each  functional  area. 

(5)  Conduct  a  series  of  tests  of  the  various  modules  separately 
to  refine  SOPs 

(6)  Applications  software  enhancements  [From  Task  3] 

(7)  Deliverable 

Task  8:  8TH  INFANTRY  DIVISION  AIRLAND  BATTLE  COMMAND  POST 
PROGRAM: 

Sub-task  8a:  Procure,  develop,  test,  and  deliver  the  division  SPADS  system 

Sub-task  8b:  Conduct  user  training 

Sub-task  8c:  Support  user  test  of  system  in  garrison 

Sub- task  8d:  Support  user  tests  of  system  in  field  environment 

Sub-task  8e:  Support  tests  of  SPADS  during  REFORGER  82 

Task  9:  BASELINE  SUPPORT  (REFORGER  82,  Able  Archer  82,  WINTEX  83, 
Caravan  Guard  83): 

(1)  Increase  the  overall  effectiveness  of  the  system 

(2)  Increase  the  user  friendliness 

(3)  Improve  clarity 

Task  10:  ON-SITE  SUPPORT  THROUGH  WINTEX  83 

Task  11:  16-BIT  MICROPROCESSOR  COMMUNICATIONS  GATEWAY: 
Sub-task  11a:  Gateway  software  conversion 


Task  12:  SPADS  SYSTEM  TRAINING  DOCUMENTATION: 
Sub-task  12a:  Written  instructional  materials: 

(1)  Users'  guide  to  the  software 

(2)  Technical  user  notes 

(3)  Concept  of  operations 
Sub-task  12b:  Audiovisual  training 

Task  13:  DCP  VIDEO  DISC  SUPPORT 


Task  13: 
Task  14: 


Task  15: 


Task  16: 


Task  17: 


Task  19: 


Task  20: 


Task  21: 


PROVIDE  SUPPORT  TO  EXERCISE  CARAVAN  GUARD  IV: 

(1)  Pre-exercise  training 

(2)  Equipment  upgrades 

(a)  ACTO  SDS  for  CBC  and  Intel  modules 

(b)  Upgrade  CGS 

(3)  Exercise  support 

PROVIDE  EXTENDED  EXERCISE  SUPPORT.  Test  objectives  and 
key  data  elements  needed  for  evaluation  of  the  exercises  will  be  identified 
for  each  CPX,  FTC-,  etc.,  so  that  Army  systems  evaluators  can  monitor 
program  progress 

PROVIDE  CONTINUED  SOFTWARE  AND  HARDWARE  SUPPORT  FOR 
THE  DCP  PROGRAM: 

( 1 )  Refine/correct  software  problems  identified  in  previous  tasks 

(2)  Continue  16-bit  microprocessor  CGS  software  development 

(3)  Provide  technical  and  hardware  support  to  AFSOUTH  and  SHAPE 
Technical  Center  in  their  DCP  activities 

SOFTWARE  SUPPORT  (through  2nd  Qtr  FY  84): 

( 1 )  Continue  development  of  1 6-bit  communications  gateway 

(2)  Continue  user  identification  requirements 

(3)  Customize  software  for  division  usage 

ON-SITE  SUPPORT  FOR  DCP  PROGRAM: 

(1)  On-site  support  personnel  (2) 

(2)  Establish  an  on-site  coordination  office  at  V  Corps  HQ 

(3)  On-site  support 

CONTINUED  SUPPORT: 

(1)  Provide  exercise  software  support 

(2)  Improve  the  SPADS  database  management  system 
Integrate  DBMS  with  automatic  output 

(3)  Investigate  the  display  of  improved  decision  graphics  information 

(4)  Implementation  of  a  TCT/MICROFIX  to  SPADS  protocol- 
for  both  8-bit  and  16-bit  gateways 

FIELDING  OF  16-BIT  COMMUNICATIONS  GATEWAY  STATION: 

( 1 )  Field  a  16-bit  microcomputer- based  communication  gateway  station 

(2)  Install  a  16-bit  microcomputer-based  CGS 

(3)  16-bit  CGS  training 


w 


v  V  .  v 


Task  22:  TRANSITION  TRAINING  AND  SUPPORT: 

( 1 )  Pre-exercise  support  and  evaluation.  Assist  commander  and  staffs 
in  identifying  SPADS  objectives  and  performance  standards  based 
upon  such  objectives 

(2)  Technical  support 

(3)  Post-exercise  reports 

(4)  Training 

(5)  Documentation-revise  User's  Manual,  produce  a  free-standing 
flip  card  reference  set 

Task  23:  SUPPORT  TO  I  CORPS  IN  TEAM  SPIRIT  84 
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APPENDIX  C 


CORPS  STAFF  MISSION  TASK  LISTSi 

ASSISTANT  CHIEF  OF  STAFF,  G1  MISSION  TASK  LIST 

1 .  Coordinate  personnel  service  support 

2.  Perform  strength  accounting  management 

3 .  Manage  replacement  operations 

4.  Track  task  force  composition  and  management  of  cross  attachments 

5 .  Supervise  strength  accounting  and  management  operations 

6.  Perform  by-name  casualty  reporting  and  monitor  personnel  status  changes 

7 .  Monitor  awards  and  decorations  program 

8 .  Manage  essential  personnel  actions 

9 .  Supervise  the  Personnel  Accounting  Section 

1 0.  Provide  administrative  service  support 

1 1 .  Operate  classified/unclassified  official  mail  and  message  distribution  center 

1 2 .  Provide  limited  essential  reproduction  services 

13.  Supervise  the  Administrative  Services  Office 

14.  Provide  financial  advice  to  the  commander 

15.  Provide  liaison  services  between  the  Area  Finance  Support  Centers 

1 6.  Coordinate  security,  deployment,  and  logistic  support  needed  for  the 
mobile  pay  teams 

1 7.  Coordinate  essential  financial  operations 


ASSISTANT  CHIEF  OF  STAFF,  G2  MISSION  TASK  LIST 

1 .  Request  maps  required  for  force  operations 

2.  Provide  input  to  the  intelligence  estimate 

3 .  Establish  liaison  with  US  agencies  and  friendly  host  country 

4.  Prepare  the  Intelligence  Annex  to  the  OPLAN/OPORD 

5 .  Task  organize  resources  to  satisfy  mission  requirements 

6 .  Request  tactical  transportation  for  Military  Intelligence  assets 

7 .  Execute  deployment 

8 .  Employ  long-range  surveillance  detachment 

9 .  Plan  for  aerial  intelligence  support  for  the  rear,  close-in,  and  deep  battles 

10.  Develop  a  security  plan 

1 1 .  Monitor  the  intelligence  effort 

12.  Collect  and  dispose  of  captured  enemy  materiel  and  equipment. 

1 3 .  Process  combat  information  from  maneuver  elements  and 
intelligence  products  from  main  CP 

1 4.  Analyze  incoming  information  from  maneuver  elements  in 
conjunction  with  intelligence  received  from  the  main  CP 

1 5 .  Disseminate  combat  information  and  combat  intelligence 

1 6 .  Maintain  the  collection  plan 

17.  Process  incoming  collection  results 

1 8 .  Establish  and  maintain  counterintelligence  technical  data  bases 

1 9 .  Provide  tactical  deception  support 

20.  Process  reports 

2 1 .  Issue  an  EW  estimate 

22.  Develop  an  EW  annex  to  the  OPLAN/OPORD 

23.  Establish  EW  section  operations 

24.  Process  incoming  intelligence  information 
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25.  Modify  ECM  and  ESM  using  data  base  and  commander’s  PIR/IR 

26.  Establish  and  control  EW  activities 

27 .  Evaluate  effectiveness  of  friendly  EW  against  the  enemy 

28.  Prepare  the  Intelligence  Estimate 

29.  Prepare  the  Intelligence  Annex  to  the  OPLAN/OPORD 

30.  Maintain  the  intelligence  data  base 

3 1 .  Process  all  source  information/intelligence 

32.  Disseminate  combat  information  and  combat  intelligence  to 
appropriate  agencies 

33.  Develop  a  data  base  to  support  the  rear  battle 

34.  Analyze  incoming  information  (from  elements  operating  in  the  rear  area) 
with  information/intelligence  received  from  the  main  CP 

3  5 .  Disseminate  combat  information/intelligence  to  the  rear  area 

3  6 .  Maintain  the  rear  battle  asset  collection  plan 

37.  Develop  and  maintain  the  OPSEC  data  base 

3  8 .  Conduct  a  vulnerability  assessment 

39.  Implement  OPSEC  measures 

40.  Update  OPSEC  plan  based  on  maneuver  unit  input 

ASSISTANT  CHIEF  OF  STAFF,  G3  MISSION  TASK  LIST 
1 .  Plan  and  coordinate  combat  operations: 

•  Conduct  mission  analysis 

•  Prepare  the  Operation  Estimate 

•  Develop  the  OPORD 

•  Recommend  the  task  organization  and  assign  missions  to 
subordinate  units 

•  Recommend  augmentation  force  requirements 


•  Supervise  fire  support  planning 

•  Plan  for  employment  of  nuclear  and  chemical  weapons 

•  Plan  for  employment  of  EW 

•  Supervise  ADA  fire  support  planning 

•  Plan  and  coordinate  tactical  air  (TACAIR)  support 

•  Plan  utilization  of  airspace 

•  Integrate  engineer  support  into  tactical  operations 

•  Inte  grate  PS  YOP  and  combat  operations 

2 .  Control  and  coordinate  combat  operations: 

•  Maintain  a  current  operations  estimate 

•  Maintain  the  current  friendly  situation  and  unit  status 

•  Coordinate  immediate  close  air  support  (CAS)  request 

•  Plan  for  Joint  Air  Attack  Team  (JAAT)  operations 

•  Supervise  the  preparation  of  fragmentary  orders  (FRAGOs) 

•  Supervise  the  coordination  of  airspace  utilization 

3 .  S  ustain  combat  operations : 

•  Program  and  supervise  OPS  EC  activities/programs 

•  Incorporate  rear  battle  planning  and  operations 

•  React  to  enemy  chemical  or  nuclear  attack 

•  Plan  and  supervise  deception  operations 

ASSISTANT  CHIEF  OF  STAFF,  G4  MISSION  TASK  LIST 

1 .  Provide  input  to  the  planning  and  decision  making  process: 

•  Develop  plans 

•  Make  recommendations 

•  Prepare  plans  and  orders 
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2 .  Coordinate  and  monitor  supply  and  operations: 

•  Maintain  information  about  the  status  of  supplies 

•  Supervise  collection  and  distribution  of  excess,  salvage  and 
captured  material 

•  Coordinate  reception  of  augmentations 

3 .  Coordinate  and  monitor  field  services: 

•  Monitor  status  of  field  service  support  units 

•  Coordinate  reception  of  combat  service  support  (CSS)  augmentation 

4 .  Coordinate  and  monitor  maintenance  operations: 

•  Maintain  records  of  the  status  of  maintenance 

•  Coordinate  reception  of  maintenance  augmentations 

5 .  Coordinate  and  monitor  transportation  services: 

•  Monitor  status  of  surface  and  air  transportation 

•  Supervise  movements 

•  Coordinate  reception  of  transportation  augmentation 

6 .  Perform  command  post  functions: 

•  Establish  section  within  the  main  CP 

•  Provide  augmentation  to  tactical  CP 

•  Provide  augmentation  to  rear  CP 


7 .  Perform  staff  coordination  in  other  functional  areas: 

•  Monitor  personnel  activities 

•  Monitor  intelligence  activities 

•  Monitor  type  of  tactical  operations 
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E.  ASSISTANT  CHIEF  OF  STAFF,  G5  MISSION  TASK  LIST 
1 .  Assist  in  the  acquisition  of  local  resources,  facilities,  and  support 


*V,r*/r*Jr  a  v 


v  A  •>  A  A  .'AkVrV 


2 .  Minimize  local  population  interference  with  U.S.  military  operations 

3 .  Prepare  an  area  assessment: 

•  Establish  liaison  with  national  officials 

•  Determine  area  resources  available  for  mission 

4 .  Advise  the  commander  on  civil  military  operations  (CMO): 

•  Formulate  CMO  plans  applicable  throughout  the  area  of  operations 

•  Provide  for  liaison  to  subordinate  units 

•  Recommend  policies  and  procedures  for  civil  affairs  (CA)  activities 
for  command  support  in  area  of  operations 

5 .  Advise  commander  on  CA  governmental  functions  in  operation  under 
the  control  of  other  agencies  in  the  area  of  operation 

6 .  Provide  the  necessary  CMO  input  into  all  operational  and 
administrative/logistic  plans  and  orders 

7 .  Advise  the  commander  on  the  impact  of  PSYOP  on  the 
civilian  population 

AIR  DEFENSE  ARTILLERY  SECTION  MISSION  TASK  LIST 

1 .  Advise  the  commander  and  staff  on  the  air  defense  operations: 

•  Coordinate  matters  concerning  ADA  operations 

2.  Coordinate,  integrate,  regulate,  and  identify  use/users  of  Army  airspace: 

•  Perform  Army  airspace  command  and  control  (A2C2) 
element  functions 

AIR  LIAISON  SECTION  MISSION  TASK  LIST 

1 .  Supervise  forward  air  controllers  (FACs) 

2 .  Supervise  the  TACP 

3 .  Advise  commander  and  staff  regarding  US  AF  support 

4.  Coordinate  close  air  support  (CAS)  with  the  fire  support  element 

5 .  Function  as  a  member  of  the  Army  airspace  command  and  control  (A2C2) 


6 .  Operate  air  request  and  tactical  air  (TACAIR)  net 

7 .  Transmit  air  support  requests 


AVIATION  SECTION  MISSION  TASK  LIST 

1 .  Plan  aviation  combat  employment: 

•  Advise  on  and  plan  aviation  cross-FLOT  operations 

•  Advise  on  attachments  and  detachments  to  subordinate  units 

•  Plan  for  aviation  augmentation 

•  Monitor  combat  operations 

2 .  Plan  aviation  combat  support  operations: 

•  Recommend  employment  of  aviation  for  air  logistics 

•  Allocate  units  for  air  logistics  operations 

•  Monitor  combat  support  operations 

3 .  Function  as  a  member  of  the  Army  airspace  command  and  control 
(A2C2)  element: 

•  Coordinate  aviation  operations  with  ADA 

•  Employ  liaison  officer  to  coordinate  aviation  operations 

4.  Supervise  aviation  training  and  safety: 

•  Monitor  aviation  safety  program 

•  Monitor  crash  rescue  program 

•  Monitor  the  crew  endurance  program 

•  Monitor  the  search  and  rescue  program 

5 .  Supervise  technical  aviation  aspects: 

•  Monitor  the  flying-hour  program 

•  Plan  aviation  flow  and  aircraft  requirements  for  strategic 
deployment  of  the  combat  aviation  battalion 
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CHEMICAL  SECTION  MISSION  TASK  LIST 

1 .  Prepare  for  chemical  section  operations: 

•  Evaluate  the  NBC  threat 

•  Initiate  attack  record 

•  Recommend  nuclear  observation  units 

•  Establish  situation  map  and  overlays 

•  Review  NBC  defense  training  program 

•  Activate  internal  NBC  SOP 

2.  Establish  chemical  section  operations: 

•  Coordinate  with  the  G2  for  NBC  data  input 

•  Conduct  vulnerability  assessment 

•  Prepare  NBC  estimates 

•  Prepare  the  NBC  portion  of  OPLAN/OPORD. 

•  Prepare  and  disseminate  wind  message 

3 .  Provide  immediate  warning  of  expected  contamination: 

•  Process  reports  of  attack 

•  Prepare  prediction  of  contamination 

•  Disseminate  warning 

•  Prepare  immediate  damage  estimate 

4.  Evaluate  NBC  contamination  data: 

•  Evaluate  NBC  4  reports 

•  Examine  contamination  data 

•  Select  reporting  unit  for  series  reports 

•  Evaluate  series  reports 

•  Prepare  and  disseminate  NBC  5  reports 

5 .  Maintain  unit  radiation  status: 


Process  tactical  dosimetry  reports 


6 .  Assist  in  planning  the  use  of  nuclear  and  chemical  weapons: 

•  Recommend  integrating  nuclear  and  chemical  fires  into  the 
scheme  of  maneuver 

•  Advise  on  allocation  and  use  of  chemical  means 

•  Plan  and  supervise  chemical  target  analysis 

•  Assist  in  nuclear  target  analysis 

7 .  Exercise  staff  supervision  over  NBC  activities  throughout  the  force 

8 .  Advise  commander  and  staff  on  NBC  matters 


PROVOST  MARSHALL  MISSION  TASK  LIST 

1 .  Supervise  and  coordinate  MP  force  requirements 

2 .  Plan  MP  portions  of  estimates,  plans,  orders,  and  reports: 

•  Prepare  a  straggler  control  plan 

•  Prepare  a  traffic  control  plan 

•  Prepare  the  MP  support  annex  to  the  OPORD 

3 .  Conduct  area  security  operations: 

•  Plan,  coordinate,  and  supervise  area  reconnaissance 

•  Plan,  coordinate,  and  supervise  MP  rear  battle  operations 

•  Coordinate  and  supervise  security  of  designated  personnel, 
units,  convoys,  facilities,  and  MSR  critical  points 

•  Coordinate  and  supervise  intelligence  collecting  and  reporting 

•  Coordinate  and  monitor  NBC  detecting  and  reporting 

4 .  Conduct  battlefield  circulation  control  (BCC)  operations: 

•  Coordinate  and  supervise  route  reconnaissance  and  surveillance 

•  Monitor  MSR  regulation 

•  Plan,  coordinate,  and  supervise  straggler/dislocated  civilian  control 


Monitor  information  dissemination  activities 
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5 .  Conduct  enemy  prisoner  of  war  (EPW)  operations: 


Coordinate  and  plan  for  the  execution  of  EPW  and  Cl 
collection  operations 


•  Coordinate  and  monitor  EPW  processing  and  evaluation 

•  Supervise,  monitor,  and  coordinate  central  collecting  point  facilities 

6.  Conduct  MP  support  to  operations  requiring  special  considerations: 

•  Plan,  coordinate,  and  supervise  MP  support  to 
river  crossing  operations 

•  Plan,  coordinate,  and  supervise  MP  support  to  military  operation 
in  urbanized  terrain 

•  Plan,  coordinate,  and  supervise  MP  support  to  the  deep  attack 

7 .  Conduct  law  and  order  operations  when  directed  by  the  commander 


COMMUNICATIONS-ELECTRONICS  SECTION  MISSION 
TASK  LIST 


1 .  Plan  C-E  support: 

•  Plan  C-E  support  with  the  staff 

•  Prepare  the  C-E  staff  estimate 

•  Monitor  signal  equipment  status 

2.  Coordinate  C-E  support: 

•  Coordinate  with  the  staff 

•  Coordinate  with  the  signal  battalions 

•  Coordinate  the  use  and  allocation  of  radio  frequencies 

•  Coordinate  COMSEC  and  SIGSEC 

•  Coordinate  with  the  C-E  section  of  higher  and  adjacent  headquarters 

3.  Supervise  C-E  activities: 
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•  Supervise  the  ECCM  program 

•  Supervise  the  CEOI 

ENGINEER  SECTION  MISSION  TASK  LIST 

1 .  Plan,  coordinate,  and  supervise  mobility,  countermobility  and 
survivability  operations: 

•  Plan  and  advise  supported  units  on  mobility  missions 

•  Perform  estimates  using  factors  of  mission,  enemy,  terrain, 
troops,  and  time  available  (METT-T) 

•  Provide  recommendations  to  the  maneuver  commander  on 
mobility  operations 

•  Prepare  a  survivability  estimate  based  on  METT-T 

FIRE  SUPPORT  ELEMENT  MISSION  TASK  LIST 

1 .  Establish  and  maintain  fire  support  facilities: 

•  Establish  continuous  fire  support  planning  and  coordination  facilities 

•  Advise  the  commander  and/or  G3  on  fire  support  operations 
and  capabilities 

•  Communicate 

•  Manage  fire  support  coordination  reports  and  information 

2 .  Prepare  and  coordinate  the  fire  support  plan: 

•  Prepare  the  "Fires"  portion  of  the  concept  of  operation 
paragraph  and  the  fire  support  paragraph  to  the  OPORD 

•  Direct  and  coordinate  the  preparation  of  the  fire  support  plan 

3.  Plan/coordinate  employment  of  fire  support  assets: 

•  Recommend  organization  for  combat 

•  Coordinate  and  plan  the  integration  of  ail  fire  support  assets  to 
support  the  maneuver  plan 

•  Coordinate  with  the  Army  airspace  command  and  control  (A2C2)  element 
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4 .  Process  and  coordinate  target  attack: 

•  Recommend  target  attack  guidance 

•  Process  planned  fire  support  requests 

•  Expedite  immediate  fire  support  requests  (tactical  FSE) 

•  Request  target  damage  assessments 

5 .  Perform  target  analysis: 

•  Perform  non-nuclear  target  analysis 

•  Perform  nuclear  target  analysis 

•  Schedule  nuclear  weapons 

•  Perform  toxic  chemical  target  analysis 

6.  Employ  nuclear  weapons: 

•  Plan  nuclear  weapon  employment 

•  Perform  post-strike  analysis  (main  FSE) 


STAFF  WEATHER  SECTION  MISSION  TASK  LIST 

1 .  Provide  weather  support  data  and  recommendations 

2 .  Prepare  climatological  studies  and  analysis 

3 .  Evaluate  and  disseminate  weather  data 


HEADQUARTERS  COMMANDANT  MISSION  TASK  LIST 

1 .  Provide  operational  control  and  planning  for  the  HQ: 

•  Supervise  the  movement  of  the  HQ  main  CP 

•  Supervise  the  internal  arrangement  of  the  HQ  main  CP 

2 .  Provide  essential  services: 

•  Provide  food  service,  medical  support,  morale,  and 
supply  service  to  the  HQ  main  CP 

•  Plan  local  security  for  the  HQ  main  CP 
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APPENDIX  D 


MCES  METHODOLOGY  DESCRIPTION 

A.  INTRODUCTION 

The  MCES  is  a  framework  for  systems  planners  and  analysts  to  evaluate  C2 
architectures.  It  is  intended  to  guide  problem  specification  and  analysis,  to  provide  concise 
conclusions,  and  enhance  decision  making.  It  is  composed  graphically  of  seven  sequential 
modules  and  a  "Decision  Maker"  block  [Figure  D.l,  Ref.  2:p.  7].  The  following 
description  is  taken  in  part  from  Dr.  Ricki  Sweet,  et.  al,  MCES:  Applications  of  and 
Expansion  to  C3  Architectural  Evaluation  [Ref.  2:pp.  10-23]  and  Sweet's  subsequent 
publications. 

B  .  MCES  MODULES 

l .  Module  1; ..  .Problem  ForrnulatiQn 

Module  1  describes  the  decision  maker's  objectives  and  needs  for  a  specific  C2 
problem.  The  decisions  being  formulated,  problem  assumptions  and  the  level  of  analysis 
required  are  taken  into  consideration.  As  a  result,  both  the  appropriate  scenarios  and 
problem  scope  are  made  explicit.  Thereafter,  the  precise  statement  of  the  problem  is  used 
in  the  second  module  to  bound  the  C2  system  of  interest  [Figure  D.2,  Ref.  2:p.  15] 

The  objectives  of  the  decision  maker  posing  the  problem  are  addressed  from  the 
standpoint  of:  (1)  the  life  cycle  of  the  military  (C2)  system,  and  (2)  the  level  of  analysts 
prescribed  [Ref  2:p,  11],  The  decision  maker’s  objectives  generally  mirror  the  various 
phases  of  the  life  cycle  of  a  military  system,  namely:  (1)  concept  definition  and/or 
development;  (2)  design;  (3)  acquisition;  and  (4)  operations.  The  appropriate  level  of 
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analysis  is  derived  from:  (1)  the  mission  the  system  is  addressing,  (2)  the  system  itself,  or 
(3)  the  components  of  the  system  or  subsystems. 

In  summary,  three  steps  take  place  in  Module  1:  (1)  the  decision  maker's  needs, 
previously  known  as  applications  objectives,  are  characterized;  (2)  the  problem  boundaries 
are  selected;  and  (3)  the  remaining  modules  are  previewed  for  their  potential  impact  on  the 
problem  statement  [Ref.  2:pp.  10-11].  In  the  implementation  steps,  several  questions 

provide  guidance,  namely: 

1 .  What  are  the  assumptions  of  the  application? 

2 .  Are  the  decisions  related  to  planning  or  implementation? 

3.  Does  the  evaluation  apply  to  an  individual  C2  system  or  require  a  comparative 
evaluation  of  several  alternatives? 

4 .  What  type  of  analysis  of  methodology  is  appropriate? 

5 .  What  part  of  the  life  cycle  of  a  military  system  is  involved? 

6.  What  mission/service  area  is  involved? 

7 .  What  level  (system,  subsystem,  platform,  etc.)  is  the  analysis  focused  upon? 

8.  What  type  of  measure,  i.e.,  how  quantitative,  will  answer  the  decision  maker’s 
questions? 

9 .  Who  is  the  decision  maker,  and  how  will  he/she  use  the  data? 

10.  Who  is  the  analyst,  and  what  background  must  he/she  have  to  properly  address  the 
evaluation? 


Module  2  identifies  the  relevant  system  elements  that  will  bound  the  system  of 
interest.  The  primary  goal  is  to  delineate  the  difference  between  the  system  being  analyzed 
and  its  environment.  To  bound  the  C2  system,  the  analyst  should  employ  the  three 
component  definition,  based  upon  JCS  Publication  1,  preliminary  to  the  implementation  of 
this  module,  of  the  C2  system.  A  C2  system  consists  of:  (1)  physical  entities — equipment, 
software,  people  and  their  associated  facilities;  (2)  structure — organization,  procedures, 
concepts  of  operation  and  information  flow  patterns;  and  (3)  (C2)  process — the 
functionality  or  "what  the  system  is  doing."  [Ref.  28:p.  22] 


WWW 


Once  the  system  elements  of  the  problem  have  been  identified  and  categorized  as 
a  result  of  the  deliberations  taking  place  in  Module  1  and  input  into  Module  2,  the  C2 
system  of  interest  may  be  further  bounded  by  relating  the  "physical  entities"  and  the 
"structure"  components  to  the  graphic  representation  of  the  levels  of  analysis,  using  the 
"onion  skin"  graphic  model  [Figure  D.3,  Ref.  2:pp  12-13].  In  this  module,  the  C2  system, 
represented  by  the  hardware  and  software  design  specifications,  is  identified  and  related  to 
the  environmental  C2  stimulus.  This  relationship  is  developed  in  terms  of  establishing 
boundaries  to  calibrate  the  system.  [Ref.  2:pp. 12-13] 

The  C2  system  statics  must  be  distinguished  from  the  C2  system  dynamics,  the 
"C2  Process."  The  statics  may  be  taken  as  the  physical  entities  together  with  the  structure 
of  what  is  needed  to  perform  C2.  The  physical  entities  include  equipment,  software, 
people,  and  the  facilities  that  house  them.  The  structure  is  represented  by  the  arrangement 
and  interrelationships  of  physical  entities  in  the  form  of  procedures,  protocols,  concepts  of 
operations  and  information  flow  patterns. 


After  the  system  is  bounded  and  the  system  elements  identified,  the  generic  C2 
process  component  of  the  system  is  identified.  Module  3  forces  the  analyst's  attention  on: 
(1)  the  environmental  "initiator"  of  the  C2  process,  which  results  from  a  change  in  the 
desired  state;  (2)  the  internal  C2  process  functions  (sense,  assess,  generate,  select,  plan, 
direct);  and  (3)  the  input  to  and  output  from  the  internal  C2  process  and  the  environment 
[Figure  D.4,  Ref.  2:p.  14]. 
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MCES  C2  Systems  Bounding 


Figure  D.4. 


MCES  C2  Process  Definition 


The  C2  Process  Definition  Module  represents  the  C2  system  in  several  ways: 

1 .  The  total  (end-to-end)  process 

2.  The  boundary  of  the  C2  components  vis-a-vis  the  non-C2  force  components 

3 .  The  structure,  especially  time  and  organization  (hierarchical)  relationships 

4.  Internal  dynamics 

5 .  Interactions  between  the  C2  system  and  the  environment 

6 .  Information  transfer 


This  definition  may  help  to  focus  an  analysis  if  several  conditions  are  met, 


namely,  that  it  is:  (1)  understood  and  agreed  upon  by  the  decision  maker;  (2)  considered  as 


the  basic  building  block  for  individual  entities  of  the  C2  system  of  interest;  (3)  measurable 


within  the  bounds  of  the  specified  problem;  and  (4)  able  to  incorporate  the  functions  of  all 


physical  entities  included  within  the  system  being  analyzed. 


For  distributed  C2  systems,  three  factors  affect  the  overall  performance:  (1)  an 


intelligence  process  aids  decision  makers  throughout  the  C2  system  in  forming  perceptions 


of  enemy  capabilities  and  intentions,  (2)  a  separate  Crosstell  (XTEL)  process  provides  a 


way  to  share  information  for  the  purpose  of  improving  the  overall  picture  of  the 


environment  and  improving  the  accuracy  of  information,  and  (3)  the  C2  process  is 


supported  by  the  two  previous  processes.  In  a  geographically  distributed  C2  system,  the 


separate  C2  processes  associated  with  separate  command  posts  will  be  netted  together 


through  the  XTEL  process;  the  intelligence  process  will  be  interfaced  with  some,  but  not 


all,  C2  processes.  How  these  processors  are  interfaced  together  will  be  defined  by 
communications  links,  protocols  and  operational  procedures.  These  interfaces  may  be 


taken  as  fundamental  to  the  architecture  of  the  C2  system,  when  the  term  "architecture"  is 


used  to  specify  the  communications  support  to  command  and  control.  [Ref.  2:pp.  70-73] 


Another  approach  in  this  module  may  translate  the  design  specifications  into  a 


network  model  of  the  C2  system  to  demonstrate  the  functionality  of  the  C2  system.  When 
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applicable  to  the  analysis  being  conducted,  the  functional  subsets  of  the  C2  process  model 
should  be  related  to  relevant  measure  is  Module  5. 

4.  Module  4:  Integration  of  System  Elements  and  Functions 
Analysis  during  Module  4  occurs  as:  (1)  the  relationships  between  the  physical 

entities  and  the  structure  (defined  in  Module  2)  and  the  staff  functions  or  processes 
(described  in  Module  3)  are  called  out;  and  then  (2)  a  technique,  such  as  directed  graphs, 
may  be  used  to  model  the  observables,  e.g.,  information  flow,  that  is  used  to  track  these 
relationships.  Information  flows  may  be  conceptually  employed  to  link  the  separate  pro¬ 
cesses  into  an  architecture  of  ihe  complete  C2  system.  The  term  "architecture"  is  used  in 
Module  4  to  emphasize  the  integration  of  the  individual  C2  systems — whose  physical 
entities,  structures  and  functions  are  coherently  related — into  a  set.  The  form  of  the  C2 
architecture  is  designed  to  support  an  evaluation  of  the  mission  effectiveness.  The  final 
form  of  the  architecture  will  include  the  process  description  and  the  system  elements 
performing  the  processes  arranged  in  a  structural  framework  [Figure  D.5,  Ref.  2:pp.  16- 
17] 

5.  Module  5;  Specification  of  Measures 

In  Module  5,  the  analyst  specifies  the  measures  necessary  to  address  the  problem 
of  interest  in  terms  of  problem,  bounding,  process  and  integration.  The  components  of  the 
C2  system  definition  may  be  employed  to  derive  an  exhaustive  set  of  relevant  measures, 
which  are  then  subjected  to  further  scrutiny:  (1)  comparison  with  a  set  of  criteria,  which 
reduces  the  number  to  a  more  manageable  set;  (2)  these  are  classified  as  to  their  level  of 
measurement — as  an  alternative,  a  minimum  essential  set  may  be  sought  rather  than  an 
exhaustive  grouping;  and  (3)  the  resulting  measures  are  used  to  determine  the  value  added 
to  the  C2  system  by  alternative  configurations  of  the  physical  entities,  structure  and/or 


processes. 


INTEGRATION  OF  SYSTEM 
ELEMENTS  AND  FUNCTIONS 


INTERRELATIONSHIPS  BETWEEN 
PHYSICAL  ENTITIES, 
STRUCTURE  AND  PROCESSES 


DETAILED  MODELING  OF  INPUT/OUTPUT 
(COUPLING) 

BETWEEN  FUNCTIONS 


BUILD  AN  ARCHITECTURE 


SPECIFY 


Figure  D.5.  Integration  of  Statics  and  Dynamics 


The  functional  subsets  of  the  C2  process  model  may  be  related  to  relevant 
measures  of  performance  (MOPs),  measures  of  effectiveness  (MOEs),  and  measures  of 
force  effectiveness  (MOFEs).  The  determination  of  the  boundary  helps  to  identify  what 
kinds  of  measures  are  necessary;  for  the  boundary  between  the  force  and  the  environment, 
MOFEs  are  appropriate.  Within  the  force  boundary,  MOEs  are  used.  For  the  subsystem — 
within  the  boundary  of  the  system — MOPs  should  be  employed.  Within  the  subsystem, 
dimensional  parameters  (DPs)  are  the  relevant  descriptive  terms.  Thereafter,  the  data 
generation  module  objective  may  be  taken  as  the  analysis  of  the  hardware  and  software 
system  specifications  against  its  design  parameters  [Figure  D.6,  Ref.  T.p.  2  4]. 

The  application  directly  influences  the  selection  of  the  measures  to  be  used  (and 
ultimately  the  means  of  specifying  those  measures).  These  applications  are  the  phases  of 
the  military  life  cycle:  conceptual,  definition,  acquisition  and  operational.  The  levels  of 
analyses  relate  to  the  focus  of  the  evaluation  (i.e.,  on  subsystems,  systems  or  missions). 

Guidelines  are  provided  in  Module  5  to  identify,  develop  and  select  measures 
that  gauge  the  C2  system's  response  in  directing  forces.  These  measures  will  provide  a 
standard  for  comparison  as  the  underlying  architecture  of  the  C2  system  is  re-configured; 
they  are  directly  tied  to  operational  issues  relating  to  the  architecture.  Table  D-l  shows  the 
criteria  for  evaluation  measures  that  may  be  compared  to  a  set  of  desired  measures  to  insure 
that  the  measures  are  useable  [Ref.  2:p.  19]. 

6  •  Module  6:  Data  Generation 


After  identifying  the  measures  for  functions,  the  analyst  addresses  the  issue  of 
how  data  will  be  generated.  Exercises,  simulations,  experiments  and  subjective  judgments 
are  all  examples  of  data  generators  [Figure  D.7],  Although  a  data  generator  may  be 
difficult  to  conceptualize  or  build,  the  output  are  numeric  values  for  the  measures 
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Figure  D.7.  Data  Generation 


specified  in  Module  5.  The  analyst  must  consider  the  following:  reproducibility  of  results, 
precision  and  accuracy,  timing  of  collection,  environmental  controls,  and  experimental  de¬ 
sign  in  Module  6.  [Ref.  2:p.  21] 


CRITERIA 

Characteristics: 

Mission-oriented 

Discriminatory 

Measurable 

Quantitative 

Realistic 

Objective 

Appropriate 

Sensitive 

Inclusive 

Independent 


TABLE  25 

FOR  EVALUATION  MEASURES 

Definition: 

Relates  to  force/system  mission 

Identifies  real  differences  between  alternatives 

Can  be  computed  or  estimated 

Can  be  assigned  numbers  or  ranked 

Relates  realistically  to  the  C2  system  and 
associated  uncertainties 

Can  be  defined  or  derived,  independent  of 
subjective  opinion 

Relates  to  acceptable  standards  and  analysis 
objectives 

Reflects  changes  in  system  variables 

Reflects  those  standards  required  by  the  analysis 
objectives 

Is  mutually  exclusive  with  respect  to  other 
measures 


Simple 


Is  easily  understood  by  the  user 
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Figure  D.8.  Aggregation  and  Interpretation  of  Measures 


factors  in  each.  Techniques  are  provided  within  MCES  to  aggregate  measures  in  a  way  that 
relates  measurement  of  the  C2  response  to  combat  outcome.  Next,  the  issues  of  measure 
causality,  sufficiency  and  independence  must  be  considered.  Finally,  the  analyst  must 
decide  if  the  decision  maker's  original  queries  can  be  addressed  by  the  MCES  analysis. 
[Ref.  2:pp.  21-22] 

C.  DECISION  MAKER 

The  products  derived  from  the  MCES  analysis  are  presented  to  a  decision  maker. 
Generally,  there  are  three  courses  of  action  available.  First,  the  results  of  the  analysis  may 
be  implemented.  Second,  the  decision  maker  may  require  a  re-iteration  of  the  MCES  based 
upon  the  need  for  further  study.  Finally,  the  process  may  be  terminated.  The  MCES  does 
not  contain  a  specific  decision  process.  The  decision  maker's  analysis  of  the  MCES 
products  may  be  entirely  subjective;  objective,  based  upon  the  numerical  values;  or  any 
combination  of  these.  MCES  only  specifies  the  framework  of  the  logical  evaluation 
process.  It  remains  with  the  decision  maker  to  reach  a  final  conclusion.  [Ref.  39:pp.  18] 

D.  USES 

MCES  can  provide  a  comprehensive  framework  for  the  areas  of  C2  analysis  and 
management.  MCES  clarifies  the  specification  of  problems  by  systematically  focusing  on 
and  indentifying  the  essential  characteristics  of  C2  systems  and  architectures.  MCES 
assists  analysts  to  effectively  conduct  C2  evaluations  for  the  decision  maker  and  operational 
user.  [Ref.  29:p.  26]] 

Table  26  shows  examples  of  the  many  uses  of  the  MCES  output  [Ref.  30:p.  23], 


TABLE  26 

MCES  APPLICATIONS 


Application 
Design  and  evaluation 


Examples 

Command  centers 
Operational  concepts 
Information  flows 
Protocols  and  priorities 


Development  of  test  plans 

for  analysis  and  evaluation  Testbed  experimentation 

Integration  of  new  equipment 
Integration  of  new  missions 

Evaluation  of  essential  MOEs  Interoperability 

Survivability 

Maintainability 

Master  planning  Capability  evaluation 

Requirement  analysis 
Deficiency  identification 
Acquisition  requirements 
Programming  priorities 


APPENDIX  E 

DEFINING  THE  FORWARD  DEPLOYED  CORPS 


A.  GENERAL 

The  corps  is  the  U.S.  Army's  largest  maneuver  unit;  it  is  the  focal  point  for  fighting 
the  AirLand  Batde.  The  corps  is  organized  to  perform  major  operational  and  tactical  tasks; 
it  takes  an  active  part  in  directing  campaigns  and  fighting  battles  [Ref.  3:p.  1-1]. 
Generally,  a  corps  consists  of  two  to  five  divisions,  a  combat  aviation  group,  corps 
artillery,  and  a  corps  support  command  as  well  as  a  large  number  of  separate  combat, 
combat  support,  and  combat  service  support  units.  Based  on  mission  and  location,  a  corps 
is  normally  classified  as  either  contingency  or  forward  deployed  [Ref.  31:p.  1-6]. 

The  forward  deployed  corps  exists  only  in  Europe  [Ref.31:p.  2-1].  It  controls 
combined  arms  forces  and  maintains  those  forces  in  a  high  state  of  combat  readiness.  The 
corps  has  established  command  relationships,  defined  missions,  assigned  areas  of 
responsibility,  and  established  logistics  facilities.  It  receives  some  support  from  the  host 
nation  and  is  affiliated  with  units  in  the  United  States  that  are  designated  for  quick 
deployment  as  reinforcements  in  wartime  [Ref.  31:p.  1-6]. 

B.  HIERARCHICAL  RELATIONSHIPS 

1 .  Superior 

The  forward  deployed  corps  is  subordinate  to  the  theater  army.  In  West 
Germany,  the  Central  Army  Group  is  composed  of  two  U.S.  and  two  German  corps. 
Each  corps  has  two  to  five  assigned  divisions. 
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The  peacetime  headquarters  of  the  forward  deployed  corps  is  structured  to 


perform  normal  staff  operating  functions  in  the  peacetime  headquarters  building.  In 
wartime,  the  demands  for  coordination  of  staff  effort  require  that  the  headquarters  be 
functionally  organized  into  command  posts;  these  command  posts  are  further  subdivided 
into  functional  modules  or  cells.  This  reorganization  facilitates  communication  among 
those  staff  elements  that  must  interact  frequently.  [Ref.  6:pp.  2-10,  2-11] 


The  corps  is  made  up  of  combat,  combat  support,  and  combat  service  support 
units.  The  commanders  of  the  corps'  principal  maneuver  units  (divisions,  regiments,  and 
separate  brigades)  direct  the  combat  activities  of  their  immediate  subordinate  maneuver 
units.  To  the  greatest  extent  possible,  all  routine  operations  that  support  the  corps  are 
controlled  through  staff  channels,  leaving  the  maneuver  commanders  free  to  direct  their 
forces.  [Ref.  3:p.  3-5] 

The  combat  units  of  the  forward  deployed  corps  are  the  armored  and  mechanized 
divisions,  the  armored  cavalry  regiment,  the  combat  aviation  group,  the  two  artillery 
brigades,  and  the  engineer  brigade.  Due  to  the  mobility,  firepower,  and  survivability  of  the 
armored  and  mechanized  divisions,  they  are  best  employed  where  combat  will  take  place 
over  wide  areas.  The  armored  cavalry  regiment  has  both  air  and  armor  units  which  operate 
as  a  combined  arms  team  over  a  wide  area  of  the  battlefield.  The  combat  aviation  group 
provides  an  air  attack  capability  in  support  of  the  corps  mission.  The  artillery  brigades  are 
designed  to  suppress,  neutralize,  or  destroy  enemy  targets.  The  engineer  brigade  performs 
three  battlefield  missions:  mobility,  countermobility,  and  survivability.  [Ref.  31:pp.  1-14  - 


The  combat  support  units  of  the  forward  deployed  corps  are  the  signal  brigade, 
the  military  police  brigade,  the  military  intelligence  group,  the  chemical  brigade,  and  the 
rear  area  operations  center.  The  signal  brigade  provides  communications-electronics 
support  for  the  corps  and  its  major  subordinate  commands.  The  military  police  brigade  has 
three  batdefield  missions:  battlefield  circulation  control,  area  security,  and  control  of  enemy 
prisoners  of  war.  The  military  intelligence  group:  provides  all  source  intelligence  products 
to  the  elements  of  the  corps  and  its  subordinate  commands;  conducts  signal  intelligence 
(SIGINT),  imagery  intelligence  (IMINT),  and  human  intelligence  (HUMINT)  collection 
perations;  conducts  electronic  warfare  missions;  and  provides  operations  security  support 
to  the  corps  and  its  subordinate  commands.  The  chemical  brigade  provides  nuclear, 
biological,  and  chemical  defense  support  to  the  corps  and  its  subordinate  commands.  The 
rear  area  operations  center  executes  and  manages  the  corps  rear  battle.  [Ref.  31:pp.  1-22  - 
1-25] 

The  corps  support  command  (COS  COM)  serves  combat  service  support  needs 
by  providing  for  personnel,  administrative,  logistical,  and  medical  needs  of  the  corps  [Ref. 
45:p.  1-25].  COSCOM's  functions  are  supply,  maintenance,  manning,  transportation, 
field  services,  administration,  reconstitution,  and  rear  area  protection  [Ref.  3:p  7-1]. 

C .  OPERATIONAL  CONCEPT 

i .  Qvficykw 

Corps  operations  generally  consist  of  phases  which  can  be  characterized  as 
offensive  or  defensive.  Our  national  strategy  dictates  that  the  initial  phase  of  operations  for 
a  forward  deployed  corps  will  be  defensive.  The  AirLand  Battle  doctrine  provides  the 
opportunities  for  commanders  to  seize  the  initiative  in  local  defensive  actions.  Follow-on 
operations  will  be  based  upon  exploitation  of  these  opportunities  to  support  achievement  of 
the  corps  campaign  plan.  [Ref.  3 1  :p  1-3] 
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The  forward  deployed  corps  fights  the  major  battles  of  a  campaign.  The  corps 
commander  directs  the  tactical  operations  of  subordinate  divisions,  separate  brigades,  and 
regiments  to  achieve  the  operational  objectives.  The  corps  integrates  the  air  suppon  from 
other  services  to  support  these  tactical  operations.  [Ref.  31pp.  1-4  -1-5] 

The  corps  operational  concept,  whether  attacking  or  defending,  is  to  defeat  the 
enemy  by  securing,  retaining,  and  aggressively  exercising  the  initiative.  [Ref.  31:p.  3-15] 


The  corps  simultaneously  fights  three  battles.  The  specific  objectives  of  the  rear, 
close-in,  and  deep  battles  support  the  objectives  of  that  phase.  The  objective  of  the  rear  is 
to  retain  the  corps'  freedom  of  action.  The  objective  of  the  close-in  battle  in  the  offensive 
phase  is  the  complete  destruction  of  enemy  divisions  at  the  Foward  Line  of  Own  Troops 
(FLOT);  the  objective  in  the  defense  is  to  retain  terrain  and  defeat  enemy  forces.  The 
objectives  of  the  deep  battle  in  the  offense  are  to  deny  the  enemy  freedom  of  action  and  to 
destroy  second  echelon  divisions;  the  objectives  in  the  defensive  phase  are  to  disrupt  the 
enemy  forward  flow  at  critical  times,  to  alter  the  enemy  commitment  plan,  and  to  find 
enemy  operational  echelons.  [Ref.  31:p.  1-3] 

3.  Qlfenae 

The  primary  purpose  of  offensive  operations  is  to  defeat  the  enemy  by  disrupting 
and  destroying  both  his  forces  and  their  support.  The  corps  executes  offensive  operations 
when  the  commander  seizes  an  opportunity  to  take  the  initiative  or  when  the  theater  army 
orders  the  offensive.  These  operations  are  characterized  by  aggressive  initiative  on  the  part 
of  subordinate  combat  commanders,  by  timely  shifts  in  the  main  effort  to  seize  opportuni¬ 
ties,  by  momentum,  and  by  the  deepest  and  most  rapid  destruction  of  enemy  forces 
possible.  [Ref.  3:pp.  5-1  -  5-3] 


The  forward  deployed  corps  and  its  allies  will  be  defending  at  the  onset  of  war 

because  of  our  national  strategy  and  the  defensive  character  of  our  alliances.  The 

underlying  purpose  of  all  defensive  operations  is  to  seize  the  opportunity  to  change  to  the 

initiative.  By  simultaneously  fighting  the  close-in  battle  and  the  follow-on  forces,  the 

forward  deployed  corps  creates  opportunities  to  seize  the  initiative.  The  corps  commander 

must  follow  Napoleon's  concise  requirements  of  the  defense: 

The  whole  art  of  war  consists  in  a  well-reasoned  and  extremely  circumspect  defense, 
followed  by  rapid  and  audacious  attack.  [Ref.  3:p  6-1] 

The  objective  of  the  defense  is  to  create  the  conditions  that  allow  the  corps  to 
withstand  the  initial  shock  of  the  enemy  attack,  to  halt  the  enemy  forces,  to  seize  the 
initiative,  and  to  go  on  the  offensive.  [Ref.  3:pp.  6-1  -6-2] 


Command,  control  and  communications  countermeasures  (C3CM)  must  be  fully 
integrated  into  the  corps'  operations  to  preserve  the  capability  of  effective  command  and 
control.  C3CM  is  the  integrated  use  of  operations  security,  military  deception,  jamming, 
and  physical  destruction — supported  by  intelligence — to  influence,  degrade,  or  destroy 
adversary  C3  capabilities  and  to  protect  friendly  C3  from  similar  enemy  actions.  The  full 
participation  of  all  corps  units  is  required  for  the  C3CM  effort.  The  commander  has  the 
opportunity  to  seize  the  initiative  and  retain  it  if  C3CM  efforts  are  used  to  disrupt  enemy  C3 
and  slow  his  decision  cycle.  [Ref.  3 1  :p.  4-28] 


D.  THE  THREAT 


The  most  serious  threat  to  the  forward  deployed  corps  is  the  Soviet  heavy 
maneuver  force.  The  Soviet  principle  of  heavy  maneuver  warfare  is  based  on  violent. 
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sustained,  and  deep  offensive  action.  Soviet  doctrine  dictates  that  mechanized  and  armored 
formations,  supported  by  aviation,  artillery,  and  air  defense,  must  seize  the  initiative  at  the 
outset  of  war,  penetrate  NATO  defenses,  and  then  drive  decisively  and  deeply  into  the  rear 
areas.  [Ref.  3:pp.  2-2  -  2-4] 

At  the  operational  level  of  war,  the  Soviets  aim  to  defeat  the  forward  deployed 
corps  throughout  the  theater  of  operations.  Their  operational  concept  is  to  attack  in  force  to 
such  a  depth  in  the  entire  corps  area  of  operations  that  defense  becomes  impossible.  To 
provide  operational  leverage  in  defeating  the  corps,  the  Soviet  army  commander  will 
introduce  second  echelon  forces  and/or  operational  maneuver  groups  and  deliver  nuclear, 
biological,  or  chemical  fires.  [Ref.  31:pp.  2-1  -  2-2] 

The  Soviet  forces  are  echeloned  in  depth  to  maintain  a  rapid  advance.  The  army 
first  echelon  is  made  up  of  motorized  rifle  and  tank  divisions.  This  echelon  will  attempt  to 
attack,  penetrate  the  corps'  forward  defenses,  and  neutralize  or  destroy  friendly  forces  up 
to  the  assigned  mission  objective.  The  second  echelon  contains  tank  divisions  and/or 
motorized  rifle  divisions.  It  attempts  to  exploit  through  th  penetration  area  to  its 
subsequent  objective,  the  corps  reserves.  [Ref.  3:p.  2-5] 

The  Soviet  operational  maneuver  group  (OMG)  is  made  up  of  combined  arms 
and  tank  armies;  it  may  be  as  large  as  a  reinforced  maneuver  division.  When  this  force  is 
deployed,  it  attempts  to  attack  at  high  speed  along  a  separate  axis  to  seize  or  destroy  deep 
objectives.  Likely  targets  for  OMG  are  the  corps  nuclear  weapons,  reserve  forces, 
airfields,  key  terrain,  and/or  political  and  economic  centers.  The  OMG  is  normally 
introduced  before  the  first  echelon  battle  is  completed  and  before  the  second  echelon  is 
committed.  [Ref.  31  :p.  2-2] 

A  major  focus  of  Soviet  doctrine  is  the  disruption  of  the  corps  rear  area  activities. 
These  operations  will  range  from  acts  of  sabotage  and  assassination  to  large-scale 
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The  corps  must  operate  with  the  knowledge  that  nuclear,  biological,  or  chemical 
weapons  may  be  used  by  the  Soviets  at  any  time.  In  the  nuclear  environment,  the  corps 
must  balance  the  tactical  requirement  to  mass  its  forces  with  the  survival  requirement  to 
disperse  them.  Special  -ff'  ns  must  be  conducted  to  conceal  or  deceive  the  actual  locations 
of  critical  units  and  facilities.  [Ref.  31:pp.  3-40  -  3-43] 

Command  and  control  facilities  and  procedures  must  be  robust  enough  to 
withstand  periods  of  intense  communications  degradation  without  major  disruption  of  the 
corps'  operational  momentum.  Command  posts  will  have  to  maintain  dispersion  and  move 
frequently  to  ensure  survival.  Command  and  control  will  have  to  be  maintained  even  when 
some  headquarters  are  destroyed.  Redundant  C2  facilities  are  required  to  maintain 
continuity  of  command.  [Ref.  3:pp.  2-19  -  2-20] 


Soviet  radio  electronic  combat  (REC)  will  pose  significant  problems  for  the 
corps  and  its  subordinate  forces.  Soviet  REC  units  collect  combat  information  by 
monitoring;  once  they  have  located  and  identified  critical  radio  stations,  they  will  attempt  to 
deceive  or  exploit  them,  disrupt  their  communications,  or  destroy  them  with  artillery  fire. 
[Ref.  3 1  :pp.  2-12-2-13] 

Defensive  electronic  warfare  efforts  will  be  critical  to  friendly  use  of  the 
electromagnetic  spectrum.  The  communications-electronics  operating  instructions  (CEOI) 


must  be  used  by  all  friendly  forces  to  maintain  continuity  of  operations.  Frequent 
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displacement  of  corps  and  divisional  CPs  will  provide  certain  protection  for  command 
facilities  and  key  personnel.  [Ref.  3:pp.  2-21  -  2-23] 

E.  CORPS  COMMANDER  AND  STAFF 
1 .  Commander 

To  effectively  fight  the  corps'  battles,  the  commander  must  position  himself  to 
command  and  control  his  forces.  Depending  upon  the  particular  circumstances  of  the 
battle,  he  may  choose  to  command  from  one  of  his  own  CPs,  from  a  division  CP,  or  from 
a  forward  vantage  point  on  the  battlefield.  The  commander  must  have  immediate  access  to 
information  throughout  the  width  and  depth  of  the  corps  area  of  operations  to  synchronize 
the  corps  war  fighting  capability.  [Ref.  3:pp.  3-9  -  3-10] 

The  corns  commander  must  "think"  brigades  and  "fight"  divisions.  He 
anticipates  the  battle  24  to  96  hours  in  the  future.  He  influences  the  battle  by  dividing  the 
battlefield,  allocating  assets,  establishing  priorities,  and  synchronizing  the  AirLand  Battle. 
The  corps  commander  has  the  assets  to  move  forces  on  the  battlefield  in  order  to  position 
them  to  gain  distinct  operational  or  tactical  advantage  over  the  enemy.  [Ref.  3:p.  2-2] 

The  commander  provides  the  direction  for  the  corps.  He  establishes  the  corps 
plan  to  drive  operational  and  tactical  planning  throughout  the  corps.  With  the  support  of 
his  staff,  the  commander  defines  the  corps  mission,  sets  its  objectives,  designs  the  concept 
of  operation,  communicates  his  intent,  assigns  missions,  and  allocates  the  resources  for 
those  missions.  [Ref.  31:pp.  4-5  -  4-7] 

Clearly  one  of  the  primary  purposes  of  the  corps  command  and  control  system  is 
to  support  the  commander  in  the  exercise  of  command.  While  each  commander  uses  his 
own  command  style,  all  commanders  must  perform  the  critical  functions  shown  in  Table  27 


2.  Staff 


Common  functions  of  the  corps  staff  are  to  obtain  and  provide  information,  to 
estimate  and  anticipate  the  situation,  to  recommend  courses  of  action,  to  prepare  plans  and 
orders,  to  supervise  execution,  and  to  coordinate  operations.  (Specific  staff  functions  are 
detailed  in  Mission  Task  Lists  found  in  Appendix  C).  The  corps  staff  must  be  capable  of: 
continuous  operations;  operating  from  multiple  sites  and  during  displacements;  continuous 
communications  with  higher  and  lower  forces;  timely  reception,  analysis,  and  presentation 
of  information  that  is  critical  to  the  commander;  simultaneous  conduct  of  current  tactical 
operatic  s,  t  lanning  for  future  operations,  and  long-term  force  support  tasks;  and  effective 
liaison  with  other  services,  allied  forces,  and  adjacent  corps.  [Ref.  3:p.  3-8] 


TABLE  27 

MISSION  TASK  LIST:  CORPS  COMMANDER 


2. 


3. 


4. 


Know  the  situation:  5. 

•  See  the  battlefield 
«  Define  mission 
Make  decisions: 

•  Provide  commander's  intent 

•  Request  necessary  augmentation 
Assign  missions: 

•  Design  concept  of  operations  6. 

•  Apply  imperatives  of  combat 
Allocate  means: 

•  Employ  augmentation  force 

•  Weight  main  effort  7. 

•  Delegate  authority 

•  Fight  the  deep  battle 


Direct  the  force: 

•  Synchronize  force  efforts 

•  Fight  the  deep  battle 

•  Concentrate/shift  combat  powers 

•  Maintain  momentum 

•  Commit  reserve 

•  Deceive  the  enemy 
Maintain  the  force: 

•  Direct  combat  service  support  priorities 

•  Protect  the  force 

•  Establish  reconstitution  priorities 
Motivate  the  force: 

•  Provide  personal  leadership 

•  Reward  performance 

•  Promote  discipline 


The  commander  requires  assistance  to  assimilate  the  information  provided 
through  the  corps  command  and  control  system.  He  needs  support  to  filter  available 
information,  demand  more  when  the  picture  of  the  situation  is  not  complete,  analyze 
pertinent  facts,  and  communicate  decisions  to  the  many  people  that  must  thoroughly 
understand  the  commander's  intent.  The  staff  directs  and  coordinates  execution  of  the 
commander’s  intent  by  providing  the  necessary  control  of  the  battle.  Table  28  shows  those 
critical  functions  performed  by  the  staff  [Ref.  6:p.  F-8].  (Appendix  C  specifies  those  tasks 
completed  by  each  staff  section  in  the  -  orps  CP.) 


Information  to  support  the  commander's  decision  making  process  lies  at  the  heart 
of  the  command  and  control  process.  Controlling  the  information  in  the  corps  headquarters 
is  a  critical  task.  Procedures  must  be  fully  defined  to  ensure  effective  control,  flow,  and 
processing  of  the  overwhelming  volume  of  information.  Positive  control  of  information 
must  be  maintained  despite  the  fact  that  the  corps  CPs  are  large,  support  many  concurrent 
functions,  and  are  frequently  spread  over  a  sizable  geographic  area.  [Ref.  31:pp.  4-36  -  4- 
39] 

All  information  in  the  corps  command  posts  must  be  evaluated  for  accuracy  and 
processed  according  to  consistent  guidelines.  Unncessary  information  should  be 
eliminated.  Command  and  control  personnel  should  have  easy  access  to  information. 
Important  information  should  be  retained  in  its  original  form.  All  information  should  be 
protected  against  the  effects  of  combat.  [Ref.  3:pp.  3-36  -  3-40] 


to 


TABLE  28. 

COMMON  FUNCTIONS  OF  THE  CORPS  STAFF 


1 .  Implement  and  monitor  commander’s  decision  and  concepts 

2 .  Keep  chief  of  staff  informed 

3 .  Collect  information 

4.  Anticipate  requirements 

5.  Make  recommendations 

6 .  Collate  and  analyze  information 

7.  Make  estimates 

8 .  Prepare  plans  and  orders 

9 .  Disseminate  information 

10.  Maintain  current  situation  status 

1 1 .  Develop  plans  based  on  missions 

1 2.  Communicate  plans  and  orders 

13.  Ensure  units  are  organized  and  equipped  for  combat 

1 4.  Implement  and  update  necessary  plans  and  orders 

15.  Supervise  forces/operations  to  ensure  compliance  with 
commander’s  concept  and  decisions 

1 6.  Analyze  and  evaluate  enemy  capabilities 

17.  Defend  against  NBC  attack 

18.  Defend  against  enemy’s  EW 


F.  COMMAND  POSTS 
1 .  Overview 

The  corps  command  post  (CP)  concept  is  based  on  the  commander  exercising 
personal  control  of  the  battle  by  using  a  small,  highly  trained  staff.  The  commander  plays 
the  central  role.  The  purpose  of  the  CPs  throughout  the  corps  is  to  support  the  commander 
by  providing  a  structural  framework  to  facilitate  his  decision  making.  The  staff  provides 
the  information  and  coordination  so  that  the  commander  can  synchronize  the  deep,  close-in, 
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and  rear  battles.  To  support  the  commander  throughout  the  corps  area,  the  headquarters  is 
normally  divided  into  three  command  posts:  tactical  CP,  main  CP,  and  rear  CP.  [Ref.  6:p. 
2-1] 

The  physical  and  electronic  signatures  of  all  corps  CPs  must  be  minimized 
consistent  with  mission  responsibilities.  Radios  and  other  emission  devices  should  be 
remoted  from  the  CPs  so  that  signatures  emanate  at  a  distance.  Physical  and  infrared 
signatures  should  be  reduced  or  eliminated  by  siting  the  CPs  in  built-up  areas.  Vehicles, 
helicopters,  and  personnel  movement  must  be  carefully  controlled  in  the  vicinity  of  all 
corps  command  posts.  [Ref.  3:pp.  3-30  -  3-31] 
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The  orientation  of  the  TAC  CP  is  more  limited  in  scope  than  that  of  the  main  CP. 
With  the  focus  on  the  close-in  fight,  the  deep  and  rear  battles  are  monitored  only  for  their 
impact  on  FLOT  operations.  Planning  is  narrower  in  scope  and  has  a  shorter  timeline — 
normally  only  about  24  hours.  Because  detailed  planning  and  coordination  to  sustain 
operations  are  conducted  at  the  main  CP,  the  TAC  CP  is  small  and  mobile.  Housed  in 
M577  CP  vehicles  or  wheeled  vehicles,  the  TAC  CP  can  operate  in  a  mobile  configuration 
or  be  dismounted  to  take  advantage  of  hardened  structures.  Design  of  this  CP  retains  100 
percent  mobility.  The  total  personnel  assigned  to  the  TAC  CP  should  be  limited  to  100  to 
120.  This  CP  relies  on  mobility  and  use  of  terrain  and  man-made  structures  for  hardening. 
The  physical  and  electronic  signatures  should  be  minimized,  and  displacements  should  be 
planned  every  12  to  24  hours.  [Ref.  3:pp.  3-24  -  3-25] 

The  organization  of  the  TAC  CP  is  simpler  and  more  flexible  because  of  the 
narrower  scope.  Despite  this,  a  functional  organization  like  that  used  in  the  main  CP 
should  be  used.  Command,  current  operations,  intelligence,  fire  support,  logistics,  and 
signal  support  cells  are  required.  Operation  of  the  TAC  CP  is  normally  the  responsibility 


( 


of  either  the  deputy  corps  commander  or  the  G3.  The  functions  and  organizational 
structure  of  the  TAC  CP  are  presented  in  Table  29  [Ref.  3:pp.  3-24  -  3-25]. 


TABLE  29 

THE  TACTICAL  COMMAND  POST 


Functions:  Organization  of  Personnel: 


1. 

Fight  the  close-in  battle. 

1 .  Command  cell 

•  Deputy  corps  commander  or  G3 

2. 

Develop  combat  intelligence  of 
immediate  interest  to  the 
commander. 

2.  G2/G3  operations  team 

3. 

Control  maneuver  forces. 

3 .  Air  liaison  team  (USAF) 

4. 

Coordinate  engineer  activities. 

4.  Fire  support  team 

•  Assistant  corps  artillery  officer 

5. 

Control  and  coordinate 
immediately  available  fire  support. 

5 .  ADA  officer 

6. 

Monitor  the  deep  and  rear  battles. 

6.  Engineer  officer 

7. 

Recommend  deep  battle  actions. 

7 .  G 1  /G4  representative 

8. 

Coordinate  requirements  to 
sustain  the  force. 

9. 

Coordinate  airspace  and  forward 
Air  Defense  Artillery  (ADA) 
operations. 

10. 

Communicate  Combat  Service 
Support  (CSS)  requirements  to  the 
main  CP. 

3-  Main  Command  Post 

The  main  CP  directs  the  C2  system  and  synchronizes  the  battle.  This  CP  has  a 
broader  orientation  and  is  more  forward  looking  than  the  other  CPs.  During  this  decade  the 
main  CP  has  been  reduced  in  size,  partially  because  of  a  shift  of  resources  to  the  TAC  CP 
and  partially  in  recognition  of  the  need  to  reduce  the  physical  signature.  The  main  CPs 


have  moved  farther  to  the  rear  to  enhance  survivability  and  to  lessen  the  need  to  displace 
frequently.  The  main  CP  is  60  to  70  percent  mobile,  but  requires  considerable  time  to 
displace.  The  size  reduction  combined  with  mobility  efforts  makes  main  CPs  easier  to 
move.  While  equipment  is  provided  to  operate  the  CPs  in  a  mobile  configuration,  the  main 
CP  is  frequently  dismounted  to  provide  increased  shelter  and  space  when  the  situation 
permits.  Dismounting  normally  increases  the  time  required  for  displacement.  [Ref.  3:pp. 
3-26  -  3-28] 

Because  of  the  size  of  the  main  CP,  it  must  be  functionally  organized  to  facilitate 
staff  communication  and  interaction.  Multi-disciplined  modules  are  created  to  enhance 
speed  and  coordination  as  well  as  reduce  reliance  on  electronic  means  of  communication  for 
information  exchange.  Modules  required  include  command,  current  operations,  plans, 
intelligence,  fire  support,  administrative/logistics,  signal  support,  and  CP  support 
(headquarters  company).  The  functions  and  organizational  structure  of  the  main  CP  are 
presented  in  Table  30  [Ref.  3:pp.  3-26  -  3-28]. 

4.  Rear-Command.  Post 

Although  the  rear  CP's  primary  function  is  sustaining  the  battle,  it  must  also 
conduct  and  control  rear  area  operations.  This  function  entails  planning  for  the  rear  battle, 
intelligence  preparation  of  the  rear  area,  terrain  management  in  the  corps  rear,  traffic 
control,  and  overall  C2  for  all  administrative  and  logistic  support  that  takes  place  in  the 
rear.  The  rear  CP  must  be  prepared  to  serve  as  the  main  CP  until  the  main  CP  is  restored 
after  attack  or  destruction.  [Ref.  3:p.  3-28] 

The  rear  CP  consists  of  the  Rear  Area  Operations  Center  (RAOC)  and  members 
of  the  coordinating  and  special  staffs.  The  commander  delegates  responsibility  for 
operation  of  the  rear  CP  to  the  rear  battle  commander,  who  is  normally  the  deputy 
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THE  MAIN 


TABLE  30 
COMMAND  POST 


Functions: 


Organization  of  Personnel: 


1 .  Fight  the  deep  battle. 


1 .  The  command  group 

•  Commander  and  Chief  of  Staff 


2 .  Monitor  the  close-in  battle. 


3 .  Monitor  the  rear  battle. 


2.  Administrative  and  personnel  sections 

•  G1  Operations  and  plans 

•  Provost  Marshall 


4.  Coordinate  and  allocate  resources 
to  sustain  the  three  battles. 


5 .  Plan  future  deep,  close-in  and  rear 
battle  actions. 


3 .  Operations  section 

•  G2/G3  operations  and  plans 
•NBC 

•EW 

•  OPSEC  management 


6.  Collate  information  for  the 
commander. 


7 .  Provide  reports  to  higher 
headquarters. 


4 .  CTOC  Support  Element  (CTOCSE) 

•  Collection,  management  and 
dissemination  section 

•  Intelligence  production  section 

•  Imagery  interpretation  section 


8 .  Provide  a  focal  point  for  the 
development  of  all- source 
intelligence. 


5.  Logistics  section 

•  G4  operations  and  plans 

•  Transportation  section 


9 .  Coordinate  requirements  for 
rear  protection. 


6 .  Civil-military  operations  section 
•  G5  cell 


1 0 .  Monitor  the  critical  radio  nets. 


7 .  Fire  support  element 

•  Artillery,  tactical  air,  naval  gunfire 
coordination  elements 


8 .  Air  space  management  element 
•  ADA  and  aviation  representatives 


9 .  En  gineer  element 


10.  Communications  center 


11.  Support  troops 

•  Signal,  military  police,  aviation, 
NBC  and  air  defense  troops 


1 2.  Liaison  elements 


1 3 .  Headquarters  commandant 


TABLE  31 

THE  REAR  COMMAND  POST 


F unctions:  Organization  of  Personnel: 

1 .  Fight  the  rear  battle.  1 .  Command  cell 

•  Deputy  corps  commander  assisted  by 
deputy  chief  of  staff 

2.  Monitor  and  support  the  deep  2.  G1  administrative  cell 

and  close-in  batdes. 

3.  Monitor  and  control  all  rear  area  3.  G4 

protection  efforts.  •  Logistics,  field  service  and 

transportation  cells 

4.  Keep  the  commander  and  staff  4.  G5 

informed. 


subordinate  commands  as  well  as  to  other  selected  combat  and  combat  support  commands 
within  the  corps  area  of  operations.  As  corps  communications-electronics  (C-E)  officer, 
the  signal  brigade  commander  advises  the  corps  commander  on  all  signal  matters  and 
exercises  technical  supervision  over  all  C-E  activities.  The  signal  brigade  employs  a  variety 
of  communications  means  to  support  the  corps.  These  means  are:  multichannel  radio,  FM 
retransmission,  radio/landline  teletypewriter,  cable/wire,  facsimile,  and  air/motor 
messenger  service.  [Ref.  6:pp.  4-16  -  4-20] 

The  corps  area  of  operations  is  extensive.  For  a  fully  manned,  forward 
deployed  corps,  the  number  of  nondi visional  troops  in  hL  area  is  approximately  120,000. 
The  corps  signal  brigade  has  more  than  5,000  personnel,  1,300  vehicles,  500  shelter- 
housed  signal  assemblages,  and  over  2,600  kilometers  of  wire  and  cable.  It  supports  about 
150  battalion- sized  units  spread  over  diverse  terrain.  The  environment  of  the  corps  signal 
brigade  includes  enemy  activity,  electronic  warfare,  and  the  dynamics  of  the  integrated 
battlefield.  [Ref.  3:p.  C-l] 


Corps  communications  are  unique  because  the  corps  is  the  interface  between 
theater  and  tactical  communications  systems.  In  the  European  theater,  theater 
communications  are  provided  to  the  corps  by  the  Army  theater  communications  command. 
This  provides  the  corps  access  to  Department  of  Defense  (DOD)  systems,  including  the 
Automatic  Digital  Network  (AUTODIN),  the  Automatic  Voice  Network  (AUTOVON),  the 
Automatic  Secure  Voice  Communications  System  (AUTOSEVCOM),  and  the  Worldwide 
Military  Command  and  Control  System  (WWMCCS).  [Ref.  3:p.  C-3] 
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